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that the lack of coordination, integration and standardization 
resulting from the proliferation of locally developed systems 
decreases logistic support and maintenance management effec- 
tiveness. It is recommended that the prescribed Naval Aviation 
configuration status accounting system and the proliferation 
of local systems be consolidated into a single integrated 
system. NALCOMIS, a program currently under development, has 
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I . INTRODUCTION 



A. BACKGROUND 

Between 1950 and 1979 the number of aircraft purchased 
by the Department of Defense (DOD) decreased from 3,000 per 
year to approximately 300 per year [Ref. 1] . However, the 
complexity and unit cost of these aircraft increased greatly. 

As a result of a smaller, more expensive, very highly sophis- 
ticated aircraft inventory and major ongoing technical advances, 
aircraft life cycles are extended and capabilities upgraded 
through changes and modifications. 

Changes to Naval aircraft are promulgated by the Naval 
Air Systems Command (NAVAIR) for specific aircraft type/model/ 
series. The actual incorporation of the changes occurs at 
the organizational, intermediate and depot levels of maintenance. 
The incorporation process is an ongoing one, and the applica- 
bility of changes varies with aircraft model, series and bureau 
number. Modifications can affect the logistic support required 
for an aircraft to varying degrees. While some changes bring 
about only minor deviations to the maintenance and supply re- 
quirements, others can cause major revisions. Maintenance 
tasks, support equipment requirements, testing procedures, 
weight and balance and spare parts can all be affected by a 
single change. Although identical configuration of all similar 
type/model/series aircraft is a goal, differing capabilities 
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are often desired to meet operational commitments and/or are 
necessary to remain within financial constraints. Consequent- 
ly a functional wing is composed of aircraft with varying con- 
figurations which subsequently have varying support requirements. 

If the changes incorporated in an aircraft are properly 
documented and the aircraft's configuration is known, the lo- 
gistic support of the aircraft can be planned and carried out. 

A major problem arises when the configuration of an aircraft 
is either unknown or incorrectly documented. In the former 
case, manhours must be expended to physically verify the changes 
that have been incorporated so that a support plan can be drawn, 
up. In the latter case, a plan will be pursued but may be 
ineffective, as the correct spare parts will not be stocked, 
correct and sufficient support equipment will not be available 
and technicians will not possess the proper training to repair 
and service the aircraft. 

This problem is further compounded in the Navy as a result 
of the deployment requirements of aviation units. Maintenance 
and supply facilities aboard an aircraft carrier are limited, 
necessitating careful planning and coordination of all support 
requirements. Under these circumstances incorrect and incom- 
plete configuration documentation can thwart logistic support 
efforts to the point where aircraft are rendered incapable 
of safe flight or mission performance. Effective maintenance 
management is highly dependent on accurate and timely config- 
uration status accounting. Consequently, configuration status 
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accounting systems are, out of necessity, an integral and active 
part of maintenance management systems during the use period. 

B. STATEMENT OF THE PROBLEM 

The Technical Directive Status Accounting System is the 
Navy system prescribed for tracking aircraft configuration. 

The personal experience of the authors at the squadron, func- 
tional wing and carrier air wing levels is that this system 
is unreliable and ineffective in providing valid and timely 
information on which to base logistic support decisions. Con- 
sequently, each functional wing or type commander currently 
employs locally initiated systems, ranging from luck to com- 
puter-aided management information systems, for monitoring 
and controlling aircraft configuration. The inability to in- 
tegrate these various systems results in degraded logistic 
support and loss of continuity for deployed airwings which 
are composed of squadrons from several functional wings. In 
addition to aircraft configuration information often being 
incomplete and incorrect, the form, presentation and accessi- 
bility are frequently inconsistent across the airwing. This 
greatly decreases the ability of logistics managers to provide 
proper and effective support for a deployed airwing. It is 
the authors' belief that the Navy requires a common, compre- 
hensive system for monitoring and controlling aircraft config- 
uration status and accountability that can be used for all 
type /model /series of aircraft. 
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C. THESIS OBJECTIVES 



The objectives of this thesis are as follows: 

1. Review the concept of configuration management and 
its application in Naval aviation. 

2. Review and evaluate the Navy Technical Directive Status 
Accounting System with regard to its effectiveness and defi- 
ciencies. 

3. Review four major local systems which have been devel- 
oped to mitigate the deficiencies of the Technical Directive 
Status Accounting System. 

4 . Provide recommendations for future direction of Naval 
aviation configuration status accounting programs. 

D. THESIS SCOPE 

Configuration management is a broad discipline that is 
divided into several different facets. Figure 1.1 shows the 
major facets--accounting, identification, control. Properly 
done, configuration management would be carried out through- 
out a system's life cycle from its conception through its de- 
sign, production and use, until it is retired. The implementation 
and interaction of the above facets vary during the life cycle, 
but all are present in one form or another. 

The scope of this thesis is limited in three respects. 

First, the concentration is on the accounting segment of con- 
figuration management and more specifically the area of config- 
uration status accounting. Second, only that segment of the 
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system life cycle in which the system is operated and main- 
tained by the user is considered. The formulation, design, 
test and production portions are only briefly mentioned with 
regard to configuration status accounting. Third, the systems 
or equipment addressed are limited to the hardware under the 
cognizance of the Naval Air Systems Command. 

E. METHOD OF RESEARCH 

Research for this thesis was conducted through a review 
of configuration management literature, contact with numerous 
Navy squadrons, functional wings, type commanders and higher 
level staffs, and a visit to Commander Naval Air Force, U.S. 
Pacific Fleet. The literature review included published ar- 
ticles written by both military and private industry managers, 
technical papers delivered at symposia and conferences. Naval 
Audit Service and Comptroller General reports, and Department 
of Defense and Navy correspondence, directives, instructions 
and technical manuals. The various squadron, functional wing 
and type commander contacts provided information on how Naval 
aviation units are currently performing configuration status 
accounting. Managers at the Naval Air Systems Command and 
Naval Material Command provided insight to future changes to 
the current Navy configuration status accounting policy. In 
addition, the personal experience of both authors contributed 
in a large degree to the information presented. 
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F. THESIS STRUCTURE 



1 . Chapter One 

This is a general introductory chapter which briefly 
presents the problem being considered and the thesis objectives. 

2 . Chapter Two 

This chapter presents a general overview of configura- 
tion management including definitions and techniques. It also 
covers a brief description of the system life cycle and its 
relationship to configuration management. 

3 . Chapter Three 

In this chapter, Department of Defense Directive 5010.19 
concerning configuration management is reviewed as well as 
Naval Air Systems Command and Naval Material Command instruc- 
tions. When reviewing Navy instructions, the subject is nar- 
rowed from configuration management as a whole to configuration 
status accounting specifically. 

4 . Chapter Four 

A brief discussion of the importance of configuration 
status accounting and its interface with aircraft logistic 
support within the Naval Air Systems Command is presented. 

5 . Chapter Five 

In Chapter Five the Technical Directive Status Accounting 
System, the prescribed system for accomplishing configuration 
status accounting within the Naval Air System Command, is 
reviewed . 
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6 . Chapter Six 



Some of the major deficiencies of the Technical Direc- 
tive Status Accounting System reviewed in Chapter Five are 
discussed in this chapter. Four local systems independently 
developed at various levels throughout the Navy to alleviate 
those deficiencies are presented. 

7 . Chapter Seven 

In this chapter an outline of the Naval Aviation Logis- 
tics Command Management Information System as it relates to 
configuration status accounting is presented. This system, 
which is in the prototype phase, has been designed to improve 
the management of aircraft maintenance including configuration 
management . 

8 . Chapter Eight 

This concluding chapter presents the authors ' views 
of where the Naval Air Systems Command stands today with re- 
gard to configuration status accounting. It also includes 
recommendations for action to be taken now and in the future. 
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II. CONFIGURATION MANAGEMENT OVERVIEW 



A. INTRODUCTION 

Configuration management is a relatively new discipline 
in military management when considered in a formal sense, al- 
though it has long been practiced informally by commercial 
companies [Ref. 2]. The advent of the missile/space race in 
the 1950 's brought with it products that were characterized 
by a high incidence of change. These changes were accepted 
results of "the technical complexity, high reliability, ex- 
tensive software, complex support, high subcontract rate and 
the essentially developmental nature of the industry" [Ref. 2]. 
The continued production, operation, and support of such pro- 
ducts require documentation and strict control over their con- 
figuration. Thus it was necessary to develop a formal system 
to replace the informal methods then in use whereby the pro- 
duct's functions and equipment could be identified, controlled 
and documented throughout its life. 

B. DEFINITION 

The literature contains several definitions, both formal 

and informal, of configuration management. Some of these follow 

Configuration Management is a management science that pro- 
vides a disciplined environment and administrative frame- 
work for the precise definition and control of product 
configuration throughout its life cycle [Ref. 2] . 

It [configuration management] defines the product, its 
components, and their interfaces. It restricts idle change. 
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and it requires precise records of the changes that are 
authorized [Ref. 3]. 

Configuration management is the art of organizing and 
controlling planning, design, development, and hardware 
operations by means of uniform configuration control, 
identification and accounting of a product [Ref. 4] . 

There are some important points in these definitions that 
deserve further comment. First of all, there is an emphasis 
on discipline, precision and organization. Fragmented, un- 
supported methods for managing configuration have been proven 
ineffective. Second, a degree of uniformity or a framework 
is stipulated. This is necessary to assure some sort of con- 
sistency of information and policy across industries. Third, 
the term "configuration" applies to the physical and functional 
characteristics of a product as well as to the information 
required to build and support it [Ref. 4]. This encompasses 
both hardware and software, design, build, test, operation and 
maintenance. Fourth, configuration management applies through- 
out a product's life. 

C. SYSTEM LIFE CYCLE 

All products or systems result from a perceived need, new 
technology or a replacement of products or systems that have 
become obsolete [Ref. 5] . They then progress through several 
phases which compose their life cycle as shown in Figure 2.1. 
Out of these phases emerges the product or system which will 
satisfy the need. As it progresses through development, its 
configuration is defined more precisely. In addition, changes 
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can occur. This process is essentially a progressive defini- 
tion of a system's configuration and it is a key concept in 
configuration management [Ref. 4]. 

The first step in this progressive definition is to define 
the system in operational terms and determine the feasibility 
of pursuing its development. This occurs during the Concept 
Formulation Phase of its life cycle. No specific hardware 
is identified at this point, but rather the basic mission the 
system must perform is identified. The output of this phase 
are the operational requirements or characteristics for the 
system. During the next phase, which is the System Definition 
Phase, physical requirements are stipulated for the system. 
These are requirements and constraints such as size, weight, 
maintainability, etc. and are the inputs for the next phase, 
the Design Phase. It is during this phase that specific hard- 
ware is fitted to the requirements, and the result or output 
is a model of the system. The model is subjected to test and 
evaluation where changes may occur. The final output will 
result in the actual configuration that serves as the input 
for the Production and Installation Phases. 

As can be seen in Figure 2.1, the following two phases, 
the Operations and Support Phase and the Modification and Re- 
tirement Phase, comprise the Use Period for the system. The 
system is transferred from the manufacturer (or producer) to 
the user where it performs its intended mission. Once the 
system enters the Use Period, configuration management is 
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essential and can become more complex. Changes may be required 
for the system to perform its originally intended function. 

In addition, changing needs or technology may modify its re- 
quired function, making further modifications necessary at 
any point in its Use Period. Prior to the Use Period, any 
changes to the system's configuration are performed and docu- 
mented by the manufacturer with the participation and concur- 
rence of the user. However, after entering the Use Period, 
the user assumes primary responsibility for change incorpora- 
tion, documentation and progressive definition of the configu- 
ration throughout this period to retirement. 

In summary, the progressive definition concept of config- 
uration management describes the process whereby, "...the con- 
figuration of a product is derived during development, determined 
during design, established during production, and maintained 
during operational support." [Ref. 4] 

D. BASELINE MANAGEMENT 

A system's configuration is monitored and controlled during 
progressive definition by means of a concept called "baseline 
management". A baseline is established by compiling technical 
documentation of the system at various points in its life cycle. 
This documentation describes the system in terms of its physi- 
cal and functional characteristics at that point and must be 
agreed upon by both the customer arid the contractor. The estab- 
lished baselines are major control points necessary for further 
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advancement through the system's life cycle. Deviations from 
an established baseline must be approved by both the customer 
and contractor and must be documented in a manner that facili- 
tates ease of configuration identification at any point in 
time. [Ref. 6] 

Baselines are established at a minimum of three and up 
to six points during the system life cycle. Samaras and 
Czerwinski identify three contractual and three recommended 
internal baselines, as depicted in Figure 2.2 [Ref. 4]. (Their 
Acquisition Phase is equivalent to the Acquisition Period in 
Figure 2.1). The contractual baselines are the Functional, 
Allocated and Product Baselines which are established at the 
end of the Conceptual, Definition and Design phases respec- 
tively. They further recommend that Design, Development and 
Production baselines be established at the indicated points 
within the Design Phase. 

In the Functional Baseline, specifications that define 
the program requirements are established. It is in this base- 
line that the identified need which originated the requirement 
for the system is defined in performance and operational terms. 

During the next phase, these objectives are allocated to 
their respective elements known as configuration items (Cl) 
within the system. Further, the design requirements for the 
elements are identified. These elements and their performance 
specifications establish the Allocated Baseline. 



23 




24 



FIGURE S.2 TYPICAL BASELIIMES 

CREF. A3 






Various internal baselines may be established during the 
Design Phase, as shown in Figure 2.2. In terms of progres- 
sive definition, this is where the configuration of the system 
that will be delivered to the customer is increasingly defined 
as the design proceeds. The culmination of this phase pro- 
duces the Product Baseline. 

Strict control of configuration deviations from the Product 
Baseline is maintained with the customer approving all changes. 
This strict control assures that the customer receives a sys- 
tem that comforms totally with both the specifications in the 
Product Baseline and all approved and documented changes thereto. 

When the system enters the Use Period, incorporation and 
documentation of changes to the Product Baseline become the 
responsibility of the customer. This thesis focuses on the 
documentation and status accounting of changes incorporated 
from the Use Period on. If efficient configuration management 
is to be successfully carried out, the Product Baseline with 
its documented changes must be maintained in a current status 
at all times. However, as the system leaves the controlled 
environment of the manufacturer and transitions to the oper- 
ational environment, its configuration management can become 
more difficult and involved. 

E. CONFIGURATION MANAGEMENT TECHNIQUES 

Monitoring and directing baseline configuration requires 
a progressively stricter control process as each baseline is 
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established [Ref. 2] . Therefore, configuration management 
is comprised of various techniques for its systematic appli- 
cation throughout the system life cycle [Ref. 4]. 

1 . Configuration Identification 

Configuration identification, as the term implies, 
identifies the physical and functional characteristics of a 
system. It is comprised of the complete system documentation 
such as specifications, engineering drawings, data lists and 
other information required to completely define the system's 
configuration and any approved changes to it. The configura- 
tion identification is detailed to the degree that serial num- 
bers of assemblies, subassemblies and parts are identified 
on the documentation. The purpose is to assure that the hard- 
ware and accompanying documentation coincide throughout the 
life cycle. 

2 . Configuration Control 

A process which starts at the beginning of and continues 
throughout the life cycle, configuration control provides the 
management framework for proposing, evaluating, approving or 
disapproving and documenting changes to the system. Config- 
uration control is limited in the early life cycle phases to 
the functional requirements (Functional Baseline) , and the 
proposed configuration and specifications (Allocated Baseline) . 
In the later phases it applies to the actual hardware and soft- 
ware which comprise the system (Product Baseline) . 
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3 . Configuration Verification 



Incorporation of approved changes may or may not pro- 
ceed as planned and/or documented. It is necessary, there- 
fore, to compare or verify the approved documented baseline 
and incorporated changes with the actual hardware and software 
contained in the system. Inherent in this configuration veri- 
fication process is the identification and subsequent correc- 
tion of configuration discrepancies by either updating the 
system to conform with its approved configuration or approving 
its present configuration as is. In the latter case, the dis- 
crepancies and buyer's approval of those discrepancies are 
noted. 

4 . Configuration Accounting and Reporting 
Configuration accounting and reporting provides the 

administrative framework for documenting a system's location, 
its component makeup by serial number and its current config- 
uration. It establishes the system for recording and reporting 
the incorporation of approved changes. The process continues 
throughout the life of the system and "establishes records 
which enable proper logistic support to be established" [Ref. 4] 

5 . Configuration Audit and Review 

Configuration audits are designed and conducted to deter 
mine if the functional and physical characteristics in the 
system's configuration identification match the system's actual 
physical and functional characteristics . These are formal 
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audits which are selectively performed on items and contri- 
bute to the establishment of the Product Baseline (especially 
on the first production article called First Article Config- 
uration Identification or First Article Configuration Review) . 
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III. CONFIGURATION MANAGEMENT STATUS ACCOUNTING 
WITHIN THE DEPARTMENT OF DEFENSE 



A. DOD CONFIGURATION MAIJAGEMENT POLICY 

According to the DOD, the purpose of configuration manage- 
ment is: 

...to assist management in achieving and documenting, at 
a controlled total life-cycle cost, the required perfor- 
mance, realistic schedule, operational efficiency and 
readiness, integrated logistics support (ILS) , config- 
uration identification and interfaces of systems, system 
segments, equipment, components, sub-components, parts, 
firmware, computer programs, facilities, and other config- 
uration items. [Ref. 7] 

To achieve this stated purpose. Department of Defense 
Directive 5010.19 prescribes uniform policies for configu- 
ration management within the military services and agencies 
of the Department of Defense [Ref. 8]. This directive requires 
that : 

1. The degree of configuration management applied to a 
given item be tailored consistent with the complexity, size, 
quantity, intended use, mission criticality and life-cycle 
phase of the item 

2. Configuration management be applied to any item devel- 
oped wholly or partially with government funding, immediately 
following approval for full-scale engineering development 

3. Configuration management be applied to any item wholly 
developed with private funding and procured by the government 
upon procurement initiation 
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4. Configuration management be continued during the de- 
ployment/operation/support phases to the extent required for 
readiness support 

DOD Directive 5010.19 further directs each DOD component 
head to designate for specific, individual items or categories 
of items, the technical organization or individual having author- 
ity and responsibility for configuration management during 
each life-cycle phase of the item being procured. The DOD 
component designated by the Secretary of Defense to have pri- 
mary responsibility is additionally responsible for developing 
and documenting interservice joint agreements for configuration 
management when more than one service is involved in the acqui- 
sition or modification of an item. 

B. CHIEF OF NAVAL MATERIAL CONFIGURATION MANAGEMENT STATUS 
ACCOUNTING 

Within the U.S. Navy, the Naval Material Command (NAVMAT) 
has been designated by the Secretary of the Navy as the con- 
figuration office of primary responsibility. Chief of Naval 
Material Command Instruction (NAVMATINST) 4130. lA and its pro- 
posed revision NAVMATINST 4 130. IB implement the configuration 
management policies of DOD Directive 5010.19. The stated con- 
figuration management objectives of NAVMATINST 4130. lA are 
to attain and maintain: [Ref. 7] 

1. Effective DOD component and contractor planning to 
ensure that the fundamental elements of configuration manage- 
ment (configuration identification, control, status accounting 
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and audits) are appropriately implemented for each config- 
uration item during each phase of its life-cycle 

2. An optimum degree of design and development latitude 
coupled with the introduction of the fundamental elements of 
configuration management at the appropriate time, degree and 
depth 

3. Visibility of development progress and compliance with 
design requirements during the acquisition process 

4. Appropriate interfaces and coordination within the 
DOD and between DOD and industry 

5. Maximum efficiency, timing, justification and visi- 
bility in the processing, control and implementation of con- 
figuration changes 

6. Adequate and verified documentation and configuration 
status accounting records to satisfy configuration identifi- 
cation and overall program requirements 

7. Desired life-cycle costs and the required level of 
operational readiness, supportability , interchangeability and 
interoperability through standardization and integrated logis- 
tic support considerations 

3 . Accurate and timely knowledge of the current config- 
uration of the configuration item 

NAVMATINST 4130. IB (Draft), if published as currently writ- 
ten, will require that configuration identification be broken 
down into three additional levels. These additional configura- 
tion levels will be implemented sequentially during the development 
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of the system and will form the bases for the Functional, 
Allocated and Product Baselines represented in Figure 3.1. 

The first identification level proposed by NAVMATINST 
4130. IB (Draft) is the Functional Configuration Identification 
which defines all essential quantitative and qualitative per- 
formance requirements, interface constraints, test and eval- 
uation criteria, and integrated logistic support parameters 
[Ref. 7]. The Functional Configuration Identification is devel- 
oped by the customer in conjunction with the contractor (if 
available) in what NAVMAT proposes to rename the Concept Ex- 
ploration Phase of the system life cycle (The Concept Explor- 
ation Phase is equivalent to the Corfcept Formulation Phase 
in Figure 2.1). The Functional Configuration Identification 
is evaluated at a Functional Requirements Review to determine 
the adequacy of the functional requirements contained in it 
and to evaluate the contractor's approach and completeness. 

Upon the completion of the Functional Requirements Review, 
the preliminary Functional Configuration Identification is 
established, and it becomes the basis for the Functional Base- 
line. After its approval, the Functional Baseline is formally 
placed under government configuration control. 

The Product Configuration Identification is the third level 
of the DOD configuration identification proposed by NAVMATINST 
4130. IB (Draft). It "defines the Cl in the form of product, 
material, and process specifications and references documenta- 
tion" [Ref. 7] . It is reviewed during the Critical Design 
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FIGURE 3.n C O IM F I G U R AT I O INJ M A IM A G E M E INI T 



Review which is held when the detailed design of the system 
has been completed but prior to its release for prototype 
manufacture and test. The Functional Configuration Identi- 
fication and Allocated Configuration Identification are also 
updated at this review. After prototype manufacture, the 
Functional Configuration Identification, Allocated Configura- 
tion Identification and Product Configuration Identification 
are further evaluated in an Integrated Pretest Review and a 
Formal Qualification Review. The former determines whether 
the system is developed sufficiently to undergo test and eval- 
uation, and the latter certifies that the Cl meets the contract 
requirements. The Product Baseline is then established from 
the Product Configuration Identification. 

NAVMATINST 4130. lA and NAVMATINST 4130. IB (Draft) provide 
specific guidance with regard to configuration status accounting 
for each phase of the configuration item's life cycle. During 
the Concept Development Phase, configuration status accounting 
is limited to the recording of all proposed changes to speci- 
fied functional and physical characteristics. The depth of 
data to be recorded and the scope and complexity of the con- 
tractor's configuration status accounting system is tailored 
to correspond to the complexity of the configuration item. 
Additionally, all configuration status accounting data is in- 
cluded in the contractor's proposed Functional Configuration 
Identification . 
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During the Demonstration and Validation Phase configuration 
status accounting is established and maintained to record and 
provide traceability of all changes to the contractor's Func- 
tional Configuration Identification. Data recorded during 
this phase of the life-cycle is additionally included in the 
Allocated Configuration Identification and is to be of suffi- 
cient detail to aid in the technical review process. Technical 
reviews are used to determine if the configuration item devel- 
opment has achieved contract milestone requirements. Addition- 
ally, during this phase, both the plan of the office of primary 
responsibility and the contractor's plans are to include pro- 
visions for identifying, continuing and expanding the config- 
uration status accounting system. 

During the Full-scale Development Phase the configuration 
status accounting system identified in the contractor and office 
of primary responsibility configuration management plan is 
implemented. NAVIIATINST 4130. IB (Draft) proposes that config- 
uration management plans be revised during this phase to record 
and provide traceability of the status of all changes to the 
Product Configuration Indentif ication as well as the Functional 
Configuration Identification and Allocated Configuration Iden- 
tification. Additionally this instruction directs that the 
configuration status accounting system implemented during this 
phase be compatible with DOD standard configuration status 
accounting systems, planned technical reviews, configuration 
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audits, and the needs of management, acquisition, evaluation 
production and integrated logistic support. [Ref. 7] 

During the Production Phase, the configuration status ac- 
counting system developed during the previous phases is further 
expanded and refined. The office of primary responsibility 
is tasked with adapting contractor configuration status account- 
ing systems to the DOD service (i.e.. Navy, Air Force, etc.) 
standard system for all configuration items not developed at 
government expense. Upon configuration item deployment, those 
activities responsible for acquisition, operation, test and 
evaluation are directed to utilize the system established by 
the respective DOD service to record and trace all changes 
to the configuration item. 

Finally, during the Deployment Phase, the configuration 
status accounting system implemented during the Production 
Phase is utilized. 

NAVMATINST 4130.1A directs the initiation and maintenance 
of a configuration record for each configuration item upon 
configuration baseline establishment. The configuration record 
when established consists of the current configuration item 
identification coupled with a history of all configuration 
changes. The record is maintained in a manner that provides 
management visibility of the configuration item. The reporting 
system utilized to maintain the configuration record consists 
of subsystems for data collection and data processing. Utilizing 
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designated reporting sources, quality assured data and stan- 
dardized elements, the data collection system accumulates 
structured records for data processing. The data processing 
system is engineered to provide timely and current configura- 
tion status accounting information to user activities. Status 
accounting output data requirements such as report formats, 
level of detail, distribution and report frequency are to be 
of an adequate level to meet management needs. 

C. NAVAL AIR SYSTEMS COMMAND CONFIGURATION MANAGEMENT 

STATUS ACCOUNTING 

The Chief of Naval Material has assigned to the Naval Air 
Systems Command (NAVAIR) overall responsibility and delegated 
it the authority for management of the configuration of Naval 
Air weapon system material items. This responsibility and 
authority are further assigned and delegated to the Director 
of the Naval Air Systems Command Headquarters Configuration 
Management Office which is responsible for developing and main- 
taining policies and procedures governing the NAVAIR Config- 
uration Management Program. These responsibilities include: 
[Ref. 9] 

1 . Providing technical and administrative direction to 
properly identify, control and record the configuration and 
change implementation status of the physical and functional 
characteristics of aircraft, weapons, weapon systems and re- 
lated equipment throughout their life cycle 
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2 . Acting as the primary NAVAIR point of contact for coor- 
dinating configuration management matters and resolving asso- 
ciated problem areas 

3. Developing, integrating and promulgating overall NAVAIR 
policies, criteria and procedures 

4. Providing policy and administrative guidance to the 
Change Control Boards which review and approve or disapprove 
engineering change proposals 

5. Providing authoritative direction and managerial assis- 
tance to functional groups and project managers in implementing 
configuration management 

6. Counseling and advising contractors regarding config- 
uration management policies, plans and procedures 

7. Interfacing configuration management procedures with 
other DOD and Navy management disciplines (e.g. Naval Aviation 
Maintenance and Material Management System and Navy Integrated 
Logistics Support System) 

8. Establishing and maintaining an overall system for 
processing and monitoring all configuration changes 

9. Developing and maintaining an aviation configuration 
status accounting system to permit timely and accurate commun- 
ication of necessary configuration data among acquisition, 
operational and support activities 

10. Conducting continuous surveillance of configuration 
management to assure compliance and improve effectiveness 
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NAVAIR Instruction (NAVAIRINST) 4130. lA implements NAVMATINST 
4130. lA and contains detailed guidance, policy and procedures 
governing Naval Aviation configuration management responsi- 
bilities assigned to the NAVAIR Headquarters Configuration 
Management Office. Specifically, in the area of configuration 
status accounting, NAVAIRINST 4130.1A identifies required con- 
figuration status accounting data, sources of data, config- 
uration status accounting systems and flow of data. It 
additionally establishes guidelines for acquisition of status 
accounting data/records/reports applicable to NAVAIR, its con- 
tractors, field activities and inventory control points. It 
further provides general guidance for physically marking con- 
figuration items for visual identification, which is essential 
to traceability. 

NAVAIRINST 4720. 1C establishes policy, responsibility and 
procedures for management of modification materials procured 
by or for the Naval Air Systems Command. The procedures out- 
lined in this instruction cover the assignment of kit identi- 
fication numbers and shipping instructions, inventory management, 
allocation and reallocation, requisitioning, receipts and issues, 
storage, excesses and reclamation. The Naval Aviation Logistics 
Center has been assigned by NAVAIR as the manager for the NAVAIR 
Modification Program and as manager for modification installa- 
tion support. 
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D. OTHER COMMAND ROLES IN CONFIGURATION MANAGEMENT STATUS 

ACCOUNTING 

NAVMATINST 5401.2 assigns the Naval Supply Systems Command 
as a principal configuration management status accounting par- 
ticipating activity. The Naval Supply Systems Command is di- 
rected to provide responsive weapon systems file support for 
the Navy's configuration status accounting system, a focal 
point for liaison with other system commands, and policy and 
procedural support for the Navy's configuration status account 
ing system. 

NAVMATINST 4130.5A establishes policies and assigns respon 
sibilities for Naval aviation configuration status accounting 
to fleet commanders, type commanders, depot level maintenance 
activities and other commands having custody of operational 
and support configuration items. These policies and assigned 
responsibilities are outlined as follows; 

1 . Fleet Commanders 

a. Support and ensure that subordinate commands and 
activities support configuration status accounting 

b. Require a configuration manager at each level of 

command 

c. Ensure coordination between maintenance and supply 
functions 

2 . Type Commanders 

a. Implement and maintain a configuration status ac- 
counting system in the fleet 
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b. Designate a configuration status accounting manager 

c. Ensure configuration change reporting is initiated 
by the installing activity and submitted by the activity having 
custody of the configuration item 

d. Sponsor configuration validations as required 

3 . Depot Maintenance Activities 

a. Report configuration changes accomplished during 
industrial maintenance 

b. Provide validation of configuration items 

c. Provide assistance to validation teams 

4 . Commands and Activities Having Custody of Operational 

and Support Configuration Items 

a. Report configuration changes by submitting Navy 
configuration change data 

b. Provide validation of configuration items 

c. Provide assistance to validation teams 
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IV. THE NEED FOR CONFIGURATION MANAGEMENT STATUS ACCOUNTING 



A. IMPORTANCE OF CONFIGURATION MANAGEMENT STATUS ACCOUNTING 

From the earliest beginnings of an organized military, 
weaponry has been modified to improve capability, reliability 
and maintainability. Documentation of these modifications, 
when accomplished, has been typically informal and non-standard. 
However, the increasing complexity of weapon systems, the large 
number of dissimilar items and the high unit cost of individual 
components has led to the development of advanced modification 
and documentation systems. Machine processing techniques have 
enabled management to generate report upon report in an attempt 
to determine the exact configuration of specific weapon systems 
at any given moment in time. Unfortunately, the majority of 
these advanced configuration status accounting modification 
and docxamentation systems lack accuracy, standardization and 
centralization . 

The number of modifications to weapon systems is on the 
rise [Ref. 10]. In the Department of Defense, there is a trend 
toward longer life cycles for equipment and systems, with moder- 
nization being substituted for new procurement [Ref. 10]. This 
situation is exemplified by the aging and much modified B-52 
bomber and F-4 fighter aircraft. 

As a result of these longer life cycles, the armed services 
have experienced a large backlog of not incorporated modifications. 
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In 1973 it was estimated that the Army, Navy and Air Force 
had approximately $304 million worth of kits on hand pending 
installation [Ref. 10]. This estimate did not include any 
modifications scheduled for completion in future years for 
which material had not yet been procured. 

Further complicating the situation is the fact that, even 
with complex record keeping systems, the Navy is frequently 
unable to determine with accuracy which modifications have 
been accomplished and which have not [Ref. 10]. This leads 
to improperly identified assets, additional physical audits 
which result in wasted manhours, duplication of effort, excess 
costs and possible hazardous conditions. 

The importance of configuration management status account- 
ing does not end with monetary, manpower and safety costs. 
Additional capability reductions result from the significant 
time lag between identification of functional problems with 
a system and implementation of corrective action. This sit- 
uation often results in emergency modifications to the system 
and hasty procurement of unproven fixes. Modifications that 
have not been fully tested frequently cause excess downtime 
due to incorporation difficulties and new deficiencies caused 
by the unproven modification. This type of situation contri- 
butes to improper documentation and status accounting. 

One of the most significant cost areas surrounding config- 
uration management status accounting concerns logistic support 
[Ref. 11]. Prior to a carrier-based deployment. Naval aviation 
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squadrons are drawn from different geographic locations and 
assembled onboard an assigned aircraft carrier. Once onboard, 
the carrier assumes full responsibility for the logistic sup- 
port of all assigned aircraft. Since the selection of aircraft 
scheduled for deployment is determined by the functional wing 
at the squadron's home base, the supporting carrier depends 
on a configuration input provided by the functional wing and 
airwing commander. This input is utilized to outfit the ship 
with the correct assortment of repair parts, test benches, 
support equipment and trained personnel. Any configuration 
differences between the aircraft provided and the configura- 
tion data utilized by the ship directly results in decreased 
operational readiness, due to a lack of optimal onboard support. 

The importance of configuration management in the Use Period 
of a weapon system's life cycle is heightened since during 
this time hardware is largely in the hands of the using agency. 
Because these military users are frequently far removed from 
the system developers in terms of time, facilities r personnel, 
communications and expertise, they are, out of necessity, fre- 
quently required to repair, modify and retrofit systems and 
components without outside assistance under conditions of urgency. 

B. THE ROLE OF CONFIGURATION MANAGEMENT STATUS ACCOUNTING 

Status accounting from an operational sense is probably 
the least understood part of configuration management [Ref. 

12]. It is often perceived as a highly expensive, monotonous 
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group of reports utilized by management to track modifications. 
Actually, configuration management status accounting is part 
of a management process that uses these reports as a means 
to an end. 

Effective configuration management status accounting re- 
quires that all changes be tracked from the time the idea for 
the change is officially proposed and recorded, through its 
investigation and evaluation, until such time as the change 
is disapproved or approved. If approved, it is further tracked 
through its incorporation into the weapon system. This includes 
tracking the incorporation of approved changes on the contrac- 
tor's production line, in operational units and in spare units 
located within the logistic support system to ensure that all 
changes are accomplished as required. 

Additionally, status accounting programs must track iden- 
tification (serial) numbers and document numbers for each con- 
figuration item to ensure an adequate level of control. Programs, 
whether manual or computer based, need to monitor the develop- 
ment of new/revised manuals and support equipment necessary 
to support the change to the product baseline. In the case 
of retrofits, programs should track the development, delivery 
and location of modification kits and their associated incor- 
poration instructions. Finally, configuration status account- 
ing must include a routine to track the configuration of all 
units in the field. 
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The increasing emphasis on lengthening life cycles of equip- 
ment to preclude new procurement will necessitate more and 
more changes if systems are to remain current with state of 
the art technology and competitive with those potential ene- 
mies of the United States. Precise knowledge of equipment 
configuration obtained through effective status and account- 
ing programs is vital to successfully achieving the required 
equipment performance, logistic support, system readiness and 
operational efficiency and effectiveness critical to warfare 
success . 
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V. CONFIGURATION MAJTAGEMENT STATUS ACCOUNTING IN NAVAIR 



This chapter contains an overview of the Technical Direc- 
tive Status Accounting (TDSA) System, the Naval Aviation Lo- 
gistics Data Analysis (NALDA) System and the interface between 
the two systems. These systems are prescribed for recording 
and maintaining modifications to equipment in the NAVAIR 
inventory . 

A. TECHNICAL DIRECTIVE STATUS ACCOUNTING (TDSA) SYSTEM 

The TDSA System is designed to encompass all weapon sys- 
tems, missiles, engines, trainers, support equipment, and re- 
pairable components under NAVAIR cognizance [Ref. 7]. To 
accommodate this diversity of configuration items, the status 
accounting system is divided into four subsystems. The sub- 
system approach provides an economical means of including the 
entire NAVAIR inventory in the configuration management pro- 
gram, while furnishing NAVAIR optional levels of data depth 
based on user requirements [Ref. 13]. The four configuration 
status accounting subsystems are; Advanced, Standard, Installed 
and Bulk. Table 5.1 provides a breakdown of the four subsystems 
and their specific applicability, accounting standards and 
identification methodology. 

The Advanced Configuration Status Accounting subsystem 
is the most costly to operate since it provides configuration 
status of selected components and support equipment by serial 



47 




* m- 




TABLE 5.1 NAVAIR CONFIGURATION STATUS ACCOUNTING SYSTEM 
[Ref. 12] 





Applicable To: 


Accounting: 


ADVANCED 
CSA SYSTEM 


10% of Support 
Equipment 
12% of Components 


Standard CSA and 
Location (2nd 
Indenture) 


STANDARD 
CSA SYSTEM 


All Aircraft 
All Engines 
10% of Support 
Equipment 
10% of Components 
All Trainers 


Unit Serial 
Number and Tech- 
nical Directive 
Status 


INSTALLED 
CSA SYSTEM 


10% of Components 
10% of Airborne 
Armament 

12 Aircraft Models 
10% of Support 
Equipment 


Mission /System 
Capability 


BULK 

CSA SYSTEM 


70% of Support 
Equipment 
63% of Components 
90% of Airborne 
Armament 


FSN/Part Numbers 
& Manufacturer's 
Code 
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number and location. It has the potential to identify, for 
example, a specific squadron aircraft bureau number in which 
a specific serial number identified component is installed. 

As indicated in Table 5.1, the use of this subsystem is limi- 
ted due to the significant resources required to support its 
operation. 

The Standard Configuration Status Accounting Subsystem 
records the incorporated or not incorporated status and appli- 
cability of technical directives against specific bureau num- 
bers or configuration item serial numbers. This subsystem 
provides the means to match listings of not incorporated tech- 
nical directives against baseline records for each configuration 
item. This capability supplies management with the basic data 
necessary to manage technical directive change kits, technical 
directive incorporation workload scheduling and configuration 
item mission capability. 

The Installed Configuration Status Accounting Subsystem 
provides configuration status accounting for selected systems 
within a weapon system. In this subsystem selected systems 
are coded by capability and compatibility for inventory and 
support requirement management purposes. Selection of systems 
for inclusion in the installed subsystem is based on the fol- 
lowing criteria: [Ref. 7] 

1. Mission and safety importance 

2. Unusual support requirements due to complexity or spare 
part shortages 
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3. Potential for frequent updating 

4. Nuitiber of different configurations possible on like 
model aircraft 

The Bulk Configuration Status Accounting Subsystem pro- 
vides configuration management for those configuration items 
not included in the previous subsystems. This system provides 
a summary of the incorporated/not incorporated status of each 
technical directive applicable to each item in the subsystem. 
Being the most economical to operate, this subsystem contains 
the majority of NAVAIR configuration items, as indicated in 
Table 5.1. 

The Configuration Status Accounting System utilizes uniform 
record formats which consist of baseline listings, and stan- 
dard configuration status accounting elements. Identification 
of status accounting elements and their related data items 
is contained in Military Standard 482A. Generally, baseline 
records are initially acquired through contract requirements 
for development and production products. Once acquired, con- 
figuration item baseline records are maintained at the Naval 
Air Technical Services Facility, Naval Aviation Logistic Center, 
NAVAIR Designated Overhaul Point, Cognizant Field Activity 
and at the Designated Field Activity. 

Accountability of technical directives issued and incor- 
porated was previously maintained through both the Technical 
Directives Master Data File by the Naval Air Technical Services 
Facility and the Configuration Status Accounting System by 
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the Naval Air Systems Command. In an effort to reduce redun- 
dant efforts and duplicate data bases, and to provide more 
current and credible information, the Technical Directives 
Master Data File and Configuration Status Accounting System 
were combined into the Technical Directive Status Accounting 
(TDSA) System [Ref. 7] . The TDSA data base contains only data 
supported by formal documentation and can be changed only be 
issuance of amended or revised technical directives. Chief 
of Naval Operations Instruction 4790. 2B establishes the poli- 
cies, procedures and responsibilities for the Naval Aviation 
Maintenance Program. Data from the Maintenance Data Collec- 
tion System of the NAMP is used in the TDSA system for record- 
kng technical directive compliance . 

TDSA data bases contain data describing attributes of Naval 
Air Systems Command technical directives such as category, 
issue/rescission dates, applicable equipment, kits required, 
planned maintenance level, work unit code, applicable engi- 
neering change proposal, and configuration control board in- 
formation. In addition to detailed records for each NAVAIR 
technical directive, TDSA data bases contain equipment records 
for all Naval aircraft and aircraft engines which describe 
the incorporation status of applicable technical directives. 
There is one TDSA data base for aircraft, one for engines, 
and one for components and support equipment. In addition, 

TDSA provides projected and actual manhour reporting, con- 
figuration status of configuration items, change kits. 
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material accounting, and summary reporting for overall tech- 
nical directive management and budgeting. The’ system is op- 
erational on a centrally located computer which is accessible 
through the geographically dispersed terminal network illus- 
trated in Figure 5.1. 

The diverse type of equipment within NAVAIR's inventory 
requires different types and degrees of management reports 
for managing the modification program. To provide an effec- 
tive yet economical method for furnishing this data, the re- 
ports listed in Table 5.2 have been tailored and standardized 
to provide desired information to meet user requirements. Each 
TDSA data base is structured on a Technical Directive/Appli- 
cability file, a Reference/Incorporated file and a History 
file. All three of these files are maintained and are acces- 
sible to all customers concerned with NAVAIR's modification 
programs as long as the equipment remains in NAVAIR's inventory. 

The Technical Directive/Applicability file is established 
and maintained by the Naval Air Technical Service Facility 
on technical directives approved by NAVAIR. The Reference/ 
Incorporated file is established and maintained by the Naval 
Aviation Logistics Center and the Naval Aviation Maintenance 
Training Group. These commands are responsible for ensuring 
that all technical directive changes reported are accurately 
reflected as incorporated. A history file is created and main- 
tained by the Naval Aviation Logistic Center and contains all 
technical directives that have been rescinded or cancelled. 
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FIQUPE B. I TDBA NETWORK 



TABLE 5.2 TDSA USER REPORTS AVAILABLE [Ref. 14] 



LSTOl 


List of all TDs and their effectivity ranges 


LST02 


List of serial numbered items showing NINC TDs 
applicable to each 


LST04 


List of serial numbered items showing the INC 
TDs for each 


LST04H 


List of serial numbered items showing the INC 
TD history data for each 


LST06 


List of serial numbered items showing both the 
INC and NINC TDs for each 


LST07 


List by TD of the serial numbered item for which 
the TD is applicable indicating the INC or NINC 
status for each S/N 


LST20 


List of serial numbered items and selected infor- 
mation about each 


LST201 


Summary information on the INC and NINC TDs by 
serial number 


LST301 


Summary listing of TDs showing INC and NINC 
statistics for each 


NAOOl 


(TD Number Assignment Report) : Provide a summary 
report of TDs, kits, and man-hours by type equip- 
ment code and series for aircraft and engines, 
and by TD code for components 


NA002 


(Aircraft Norm Report) : TD calculated NINC manhour 
norms for a given number of items of a given type 
of equipment 


NA003 


(Modification Summary Report) : Provides matrices 
of INC/NINC TDs by serial numbers 


NATOl 


(Aeronautical Technical Directive Index — Format 1) 
List of TDs in the sequence of the TD file with 
selected information about each i.e., CCB and ECP 
number 


NAT 10 


(NAVAIR-00-500C Report) : Lists selected TDs appli- 
cable to a type, model, series aircraft 
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TABLE 5.2 (Continued) 



NAT 11 
REP 21 



Complete list of all information applying to a TD 
that is in the TD/Applicability Files 

(Reference File Listing) : Complete list of all data 
applicable to select serial numbered items including 
INC/NINC TDs 
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The history file was established to reduce active file volume 
and operating costs and to provide a permanent record of his- 
torical modification transactions. [Ref. 14] 

Aircraft reporting custodians (squadrons) and their func- 
tional wings (staffs) are provided quarterly summary reports 
of all technical directive transactions applicable to aircraft 
under their cognizance. These reports are referred to as the 
TDSA List 2 and TDSA List 4 reports. The TDSA List 2 lists 
all published technical directives applicable to but not in- 
corporated in assigned bureau/serial numbers, and the TDSA 
List 4 lists all published technical directives applicable 
to and incorporated in assigned bureau/serial numbers. Fol- 
lowing verification with the previous listings, the newly re- 
ceived listings are maintained in the technical directive 
section of the aircraft /engine logbook. It is the responsi- 
bility of reporting custodians to report all list omissions 
or errors to the Naval Aviation Logistic Center TDSA Officer 
(Code 242). Annually, reporting custodians receive the TDSA 
List 4H (Historical Incorporated Data) which, following veri- 
fication is also maintained in the aircraf t/engine logbook. 

The TDSA List 4H indicates the incorporation status of all 
applicable technical directives. 

Naval Air Rework Facilities are tasked to audit each air- 
craft/engine during overhaul and correct all discrepancies 
found in the TDSA Lists 2 and 4 on file in the aircraf t/engine 
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logbook. This audit by depot facilities was implemented to 
provide a stable, consistent and reliable means of ensuring 
data accuracy throughout the fleet. [Ref. 14] 

B. NAVAL AVIATION LOGISTICS DATA ANALYSIS (NALDA) SYSTEM 

In 1970, the Naval Aviation Logistics community recognized 
that all of the elements of the logistics network — repair parts, 
support equipment, personnel skills, technical data and facil- 
ities must be considered together because of their close rela- 
tionship and interdependence [Ref. 15]. In recognition of 
this requirement, the concept of the Naval Aviation Logistics 
Data Analysis (NALDA) system was formulated. The central ob- 
jective of the NALDA system is to provide a significantly im- 
proved logistics data analysis capability to support the NAVAIR 
Headquarters, fleet type commanders and field activities in- 
volved in the analysis and management of logistics and engi- 
neering [Ref. 15] . NALDA has achieved this objective by providing 
a "state-of-the-art" NAVAIR corporate data base system tailored 
to support various NAVAIR logistic management information sys- 
tems, user data analysis programs, and interactive query 
requirements . 

The NALDA prototype system first became operational in 
May 1976, and was a major step in total system development. 

The prototype demonstrated that integrated application pro- 
grams and interactive data analysis can enhance material 
readiness, safety and resource allocation [Ref. 15]. NALDA 
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moved from prototype to Phase 1 operational capability in 
October 1981 with the following system applications: 

1. Analytical Maintenance Program Analysis Support System — 
a tool to support reliability centered maintenance concepts 

2. Aviation Maintenance Engineering System — a tool to 
increase operational readiness by correcting maintenance and 
supply problems 

3. TDSA — a tool to manage the incorporation of technical 
directives in aircraft, engines, components and ground support 
equipment. This system provides a duplicate data base that 
can be directly accessed by user activities. 

NALDA Phase II will incrementally incorporate numerous 
additional programs during fiscal years 1982 through 1985. 
Programs for Phase II incorporation which have impact on con- 
figuration management status accounting are; [Ref. 15] 

1. Engine composition and tracking — a program to project 
and track material and workload requirements for serial num- 
bered engines and critical engine components 

2. Engineering change proposal, tracking and evaluation — 
a program to monitor and evaluate all engineering change pro- 
posals from inital action by the NAVAIR change control board 
to ultimate disposition, including their installation as tech- 
nical directives 

3. Configuration management serial number accounting and 
tracking — a system to track and manage the configuration status 
of aviation weapon systems to support NAVAIR application programs 
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4 . Kits management information system — a program to track 
the location, quantity and condition of technical directive 
change kits 

Since NALDA is an analysis system and not a data collec- 
tion system, it imposes no additional data reporting burdens 
on the fleet. NALDA receives maintenance, supply, configura- 
tion, operations, material, safety, readiness and other logis- 
tics data from existing data collection systems such as the 
Maintenance Data Collection System, the Naval Aviation Main- 
tenance Program, the Aviation Supply Office, Master Data File, 
Weapons System File, Naval Air Rework Facilities and many other 
sources as indicated in Figure 5.2. 

This data is entered into a centrally integrated data bank 
organized using a data base management system named System 
2000. The System 2000 query language makes it possible for 
non programmers to communicate directly with the computer. 

The principal function of the System 2000 data base manage- 
ment system is to edit and organize input data, then load and 
subsequently update the data bank. 

In addition, the data base management system can calculate 
various summary and statistical data, develop graphics, per- 
form simulations and provide various modeling and forecasting 
outputs, as illustrated in Table 5.3. NALDA is an evolution- 
ary management information system which will incrementally 
expand through subsequent development phases as new user re- 
quirements are approved for incorporation. 
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TABLE 5.3 NALDA [Ref. 15] 



SYSTEM 2000 DBMS 

* Natural Language 
Interactive Query 

* Report Writer 
User Strings 

* Cobol, Fortran, PLI 



SPECIALIZED SOFTWARE 

* Statistics 

* Graphics 

* Simulation 

* Modeling 

* Forecasting 



APPLICATION SUBSYSTEM INTERFACES 



* 


AMPAS 


k 


SMRA 


* 


AMEN 


k 


RIP 


* 


TDSA 


k 


DAP 


■k 


AIMI 


k 


MIR 


k 


VAMOSC-AIR 


k 


LSAR 


k 


SM&R-IMP 


k 


ECP-TRAK 


k 


ICRL-IMP 


k 


COMSAT 


k 


ECOMTRAK 


k 


CURES-INT 


k 


MPI 


k 


KITS-MIS 


k 


SNOAP 


k 


SRC -REP 



USER COMMUNITY 
MANAGERS 
ENGINEERS 
LOGISTICIANS 
ANALYSTS 
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VI. LOCAL CONFIGURATION MANAGEMENT STATUS ACCOUNTING SYSTEMS 



In this chapter the deficiencies of the TDSA and NALDA 
Systems are discussed. The overwhelming necessity for real 
time and accurate aviation maintenance management information 
has lead to the development of numerous independent systems 
at various management levels throughout the Navy. (Because 
these systems are not standardized, distributed or utilized 
on a NAVAIR-wide basis, they are referred to as "local" sys- 
tems throughout the remainder of this thesis.) Although highly 
maintenance management oriented, local systems often integrate 
accurate and timely configuration status accounting data to 
improve overall information system effectiveness. Four local 
systems representing specific airframe, engine and avionic 
applications are reviewed. 

A. TDSA DEFICIENCIES 

In December 1978, following a comprehensive audit of the 

NAVAIR modification program, the Naval Audit Service reported: 

The TDSA system, designed to provide the current config- 
uration of all Naval aircraft and approved modifications 
to be installed, is replete with incomplete and unrelia- 
ble data. As a result the system output is not reliable 
without extensive reconciliation. [Ref. 16] 

As part of this evaluation, the Naval Audit Service reviewed 
the NAVAIR Technical Directive Application File for airframe 
changes, updated through 31 December 1977. The Application 
File contained 14,832 records of which 5,983 involved kit 
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installations either already incorporated or to be incorporated. 
Using computer aided analysis, the Naval Audit Service found 
the following deficient areas: 

1. Missing Data. Thirty-five percent of the 14,832 records 
were lacking manhour accounting data and thirty-two percent 

of the 5,983 records concerned with kit installations were 
lacking cost accounting data. 

2. Unreliable Data. Of the 14,832 records reviewed, 7,757 
(fifty-two percent) had actually been rescinded; however, only 
1,833 (twelve percent) of the TDSA records were identified 

as being rescinded. Records indicated that 207,355 modifi- 
cation kits had been incorporated. However, only 49,329 kits 
were actually recorded as having been procured. Additionally, 
a review of aircraft inspections (bulletins) revealed a quan- 
tity of 348 kits incorporated, despite the fact that these 
inspections do not require kits. Finally, a comparison of 
records indicating the total number of "equipment items affected" 
with records indicating total number of technical directives 
incorporated/not incorporated revealed 211,093 units affected 
and 256,109 incorporated/not incorporated technical directives, 
an error of eighteen percent. 

Although the above examples are few in number, they repre- 
sent the magnitude of the problem that still exists today. 

In 1982, the Naval Audit Service reported that the Naval Air 
Systems Command and Naval Supply Systems Command "still have 
not agreed on how to carry out and implement a configuration 
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status accounting program and that management within the 
Department of the Navy has not resolved the problem." [Ref. 

17] It further stated that the continued lack of accurate, 
complete and timely configuration information is adversely 
affecting fleet operations, modification kit inventory man- 
agement, depot maintenance and supply support within the Naval 
aviation community. 

Naval operating forces are becoming increasingly concerned 
about system performance degradation resulting from config- 
uration errors. Commander, Naval Air Force, U.S. Atlantic 
Fleet studied fifty-eight configuration related mishaps that 
occurred during the eighteen month period ending 30 June 1978. 
The study found that the Navy incurred over $100 million in 
aircraft damage during that period as a result of inadvertent 
aircraft component removal, change removal, installation of 
incompatible replacement components and failure to incorporate 
authorized changes. [Ref 16] 

A study conducted by the Fleet Material Support Office 
in 1980 revealed that aviation consolidated allowance parts 
lists for recently deployed F-14 squadrons did not authorize 
twenty-five percent of the required parts [Ref. 18] . The lack 
of complete, accurate and timely configuration status account- 
ing data contributed significantly to these problems [Ref. 18]. 

Although the Naval Aviation Logistics Command Management 
Information System (NALCOMIS) is being designed to provide 
Naval aviation activities with an automated configuration status 
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accounting system, there is no credible schedule indicating 
when NALCOMIS will be implemented. This, coupled with the 
inadequacies of current information systems, has forced air- 
craft maintenance managers at all levels to take aggressive, 
independent action to obtain or produce local systems that 
improve their control over configuration management. 

Special purpose management information systems are addi- 
tionally created because it is often less expensive, easier, 
and faster to construct a new system than to correct existing 
systems or accelerate implementation of planned systems. In 
many cases, managers simply cannot or will not wait for a pro- 
perly planned and implemented management information system. 

In other cases, limitations in the budget process encourage 
proliferation. Although the limited cost of a specialized 
system to satisfy a single project is easily justified, rede- 
sign of existing systems is sometimes more cost-effective and 
results in a system with implicit integration. 

Local systems range from personal hardware and software 
to sophisticated. Navy funded, contractor supported systems. 
With few exceptions, these systems are not compatible with 
each other or NALCOMIS, and they are not standardized in any 
way. Although numerous systems exist. Table 6.1 is a listing 
of those configuration management related local systems cur- 
rently recognized by the Navy. The remainder of this chapter 
discusses four significant local systems that have been 
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as 




TABLE 6.1 LOCAL CONFIGURATION STATUS ACCOUNTING SYSTEMS 



MAINT LEVEL/ 



ACRONYM 


SPONSOR (S) 


CONTRACTOR (S) 


FUNCTION 


SIDMS 


CNAL 


PRD 


I/SSC 


ARMS 


MAG 14/ 
NAVAIR 


PCI 


0/I/SSC 


FAMMS 


NAVSUP/ 

TYCOMS 


NAVY 


I/SSC 


AMS 


NAVMAT 


CACI/IBM 


0/1 


Measure 


NAVAIR 


CERBERONICS/ 

DELPHI 


I 


TMS 


NAVAIR 


MAC AIR 




ADPE/FMF 


CMC 


UNK 


O/I Partic 


TICS 


NAVAIR 


NAVY 




LAMS 


NALC 


SAI 


IMRL 


ATSS 


OPMAV 


SYSCON 


Training 
Personnel 
Asset Mgt 


LINDA 


CNAP 


SYSCON 


General 


SPORT 


CNAL/ 

OCEANA 


WANG 


SSC 


* VAMP 


CNAP/AIMSO 


Mantech 


VAST Mgt 


* CMIS 


CNAP 


GRUMMAN 


0 


* ECOMTRAK 


NAVAIR/ 

NALC 


VSE 


O/I 


* CAMS/ 
PLS 


CNAL 


SYSCON 


0 



* Reviewed in this chapter 
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developed to independently manage configuration of avionics 
equipment, airframes and engines. 

B. VERSATILE AVIONICS SHOP TEST (VAST) AVIONICS MANAGEMENT 

PROGRAM (VAMP) 

The TDSA system currently provides no capability for track- 
ing changes to avionics weapon replaceable assemblies incor- 
porated at the intermediate or depot maintenance levels. 

Although data recording these changes is entered in the Main- 
tenance and Material Management System in the same way that 
airframe change incorporations are entered, the Naval Aviation 
Logistics Center produces no consolidated list for avionics 
changes that are equivalent to the airframe change List 2 and 
List 4. Likewise, avionics change incorporation information 
is not available through NALDA. Because the maintenance data 
collection system does not have the capability to track avionics 
components by serial number, avionics technical directive in- 
corporations are tracked only be numbers of change kits docu- 
mented as having been used. Consequently, each intermediate 
maintenance activity has devised and pursued its own system 
for component serial number configuration status accounting. 

Due to the magnitude and complexity of the task, most of these 
systems are manually tracked within the workcenter that incor- 
porates the change in the specific piece of avionics equipment. 
However, one area where a computerized system has been developed 
is in those workcenters where the weapon replaceable avionics 
assemblies are repaired on the Versatile Avionics Shop Test 
(VAST) bench. (■-, 



Versatile Avionics Shop Test is a computer controlled test 
system designed to be used by intermediate and depot level 
aviation maintenance activities. VAST is composed of a group 
of independent, general purpose stimulus generator and mea- 
surement instruments called building blocks that are necessary 
to test highly sophisticated avionics equipment. Because of 
building block independence, VAST stations can be readily adapted 
to support a wide variety of present and future avionics systems. 

Growing interest in and increased utilization of automatic 
test equipment, coupled with concern over avionics equipment 
configuration management has resulted in development of a pro- 
totype automated VAST management program by Mantech Corporation. 
The VAST Automated Management Program (VAMP) currently being 
prototyped has the following specific objectives: [Ref. 19] 

1. Decrease weapon replaceable assembly (WRA) turn-around 
time through better utilization of shop replaceable assembly 
(SRA) pool and other assets awaiting parts 

2. Decrease the required management manhours to track 
WRA run selection parameters allowing more time for direct 
supervision 

3. Decrease techniciam manhours expended on paperwork 
allowing more time for WRA production 

4. Provide serial number tracking of VAST building blocks, 
VAST supported WRAs and VAST supported SRAs 

5. Increase identification of VAST supported problem 
components 
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6. Improve configuration management of VAST supported 
weapon replaceable assemblies 

7. Increase utilization of VAST station hardware through 
more efficient control of station configuration 

8. Collect station information for "real time" trend anal- 
ysis useful in detecting problem areas, or identifying compo- 
nents which require special attention 

9. Reduce documentation data errors through the use of 
automatic verification routines within the system 

Currently VAMP divides VAST operations into four main func- 
tional areas; 1) supervisory function programs, 2) maintenance 
action form processing, 3) station status programs and 4) parts 
availability programs. As these objectives indicate, VAMP 
is more than just a configuration status accounting system. 
However, only those methods and procedures generally dealing 
with configuration management of avionics equipment and the 
VAST station itself are addressed here with respect to each 
of these functional areas. 

1 . Supervisory Functions 

Original Maintenance Action Form input to the VAMP 
system is done through the use of this function. In addition, 
existing maintenance action form data currently within the 
system can be modified or corrected. Other basic supervisory 
functions include ad-hoc querying of maintenance data and ac- 
cessing preformatted reports and lists. 
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With regard to configuration management, this function 
contains a change monitoring program that automatically exa- 
mines every weapon replaceable assembly part number and serial 
number as it is entered into the system to determine if an 
avionics change needs to be incorporated in that assembly. 

If a change is required, the program automatically prepares 
the maintenance action form and posts the pending maintenance 
action to the appropriate files. This program provides manage- 
ment with the capacity for real time identification of the 
exact configuration status of any given VAST supported weapon 
replaceable assembly. 

2 . Maintenance Action Form Processing 

The documentation of material to be ordered, including 
avionics change kits, and the completion of maintenance action 
forms is achieved automatically within this function. In the 
case of completed avionics changes, the incorporation data 
is entered in the computer under the appropriate menu driven 
option, and the system prints the necessary data on the proper 
form. Configuration status changes resulting from any of these 
actions are automatically posted to the appropriate files. 

Real time status of all outstanding maintenance actions 
(including technical directive incorporations) are available 
for verification or ad-hoc status checks. Queries can be made 
by work unit code, status (i.e., awaiting maintenance, awaiting 
parts) , part number, serial niomber, avionics change number 
or supply requisition number. 
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3 . 



Station Status Programs 



Procedures for reporting the configuration of the VAST 
system itself have been incorporated. VAMP has been designed 
to track and record station status data for one or all sta- 
tions. Before any station status change can be made by the 
operator, the VAMP system performs verification to ensure that 
proper conditions exist throughout the VAST system to justify 
a status change (i.e., station status is not being changed 
from down to up when there is an outstanding maintenance action 
against the station) . This verification is designed to ensure 
maximum data integrity of configuration identification within 
the VAST system. 

Under VAMP, VAST station configuration status can be 
quickly displayed and reviewed. Building blocks currently 
installed in a given station can be identified to the serial 
number level, thus providing an accurate real time station 
configuration tracking system. Maintenance and supply actions 
are automated for all actions involving building blocks. This 
automated function includes documentation of all removal, in- 
stallation, cannibalization and calibration actions. Addition- 
ally, the system provides for automated supply requisition 
and maintenance /supply status change documentation. 

4 . Parts Availability Programs 

The ability to quickly determine the availability of 
required parts plays a significant role in maximizing VAST 
workcenter throughput. As a result, procedures that allow 
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parts availability to be quickly and easily determined have 
been incorporated into this function. The system can be queried 
to determine whether or not a required part or technical direc- 
tive change kit is available for issue by the supporting Supply 
Department . 

Another useful feature of VAMP with regard to parts 
requirements and availability involves a set of routines which 
screen the configuration of all awaiting parts assets for re- 
quired parts. Rather than allow these assets to remain unused 
and send still another unit to the awaiting parts locker, the 
required parts can be cannibalized from a unit already awaiting 
parts so that the other unit can be made ready for issue. 

Telephone discussion with VAMP managers at the prototype 
site indicates that the VAMP system has significantly enhanced 
management of the VAST workcenter and configuration control 
of the assemblies under VAST cognizance. However, there is 
no quantitative data available to determine its actual level 
of effectiveness [Ref. 20] . This lack of data is a result 
of the relatively short time VAMP has been in operation and 
the fact that it has been tested at only one site. 

The major limitation currently impacting VAST/VAMP 
management is supply support. The inventory data base of re- 
placement parts and technical directive change kits has not 
been entered into the system. Consequently, VAMP can not deter- 
mine if a replacement part is actually in stock. Another 
supply-related limitation involves the set of routines which 
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search awaiting parts assets for needed parts. This feature 
is utilized only eight hours per day Monday through Friday 
because of a shortage of supply personnel. Since maximum uti- 
lization of the VAST station requires 24-hour operation, greater 
access to supply data could provide significant increases in 
VAMP efficiency and effectiveness. 

VAMP provides an effective means of monitoring, con- 
trolling and accounting for avionics component configuration. 

Fully compatible with NALCOMIS, VAMP is the only automated 
system in the Navy developed specifically to manage avionics 
components. Given the lack of interface systems, VAMP is only 
capable of tracking component locations when the component 
is physically within the VAST workcenter. Additionally, VAMP 
is designed to manage only VAST supported components which 
comprise a small percentage of the total NAVAIR avionics inventory. 

The VAMP system is a first generation management infor- 
mation system enhancing VAST workcenter throughput and config- 
uration management of avionics weapon replaceable asseinblies. 

Data provided by VAMP developers indicates that the system 
is currently being expanded to solve some of the deficiencies 
and limitations discussed herein [Ref. 19]. If provided with 
upline reporting capability to NALCOMIS and NALDA, and if ex- 
panded to include all intermediate level weapon replaceable 
avionics assemblies, VAMP has the potential to become an even 
more effective avionics configuration accounting system. VAMP 
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may lead the way to increased readiness by combining effective 
decision-making tools and useable management information for 
configuration status accounting. 

C. CONFIGURATION MANAGEMENT INFORMATION SYSTEM (CMIS) 

The Configuration Management Information System (CMIS) 
is a computerized system designed to reflect the present sta- 
tus of all major changes affecting supported aircraft at the 
organizational level. It was developed by Grumman Aerospace 
to provide summary level information concerning configuration 
change requirements and configuration status in the complex, 
dynamic environment of multiple aircraft configurations at 
multiple sites and overhaul facilities. CMIS provides a wide 
variety of reports for planning and management visibility which 
highlight the remaining actions necessary to ensure incorpor- 
ation of changes into all affected aircraft. An on-line, single 
source data base accessible through a nationwide tele-network 
enables CMIS to support a wide variety of user applications 
and requirements. The CMIS system utilizes an IBM 370 computer 
located at Griunman ' s Bethpage, New York facility. The language 
employed for the system is ANS COBOL Version 4. 

The functional system consists of two separate data bases 
(Figure 6.1); [Ref. 21] 

1. Master Data Base with the following capabilities: 

a. Update data contained within the system 

b. Create new reports 
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c. Control site access 

d. Produce all standard/catalogued reports 

e . Provide check output option 

2. Duplicate Data Base with the following capabilities: 

a. Produce selected standard/catalogued reports 

b. Provide check output option 

CMIS design permits only the users of the Master Data Base 
(Grumman) the capability to develop new reports. Duplicate 
Data Base users (Fleet) are permitted access to only cata- 
logued existing reports. Adequate flexibility, however, has 
been build into the system to provide unique user reports to 
a specific user upon request. 

Data input to the Master Data Base is accomplished entirely 
by Grumman Aerospace in Bethpage. The Product Baseline for 
each specific block of aircraft bureau numbers is entered during 
production and updated during the Operations and Support Phase 
with data provided from user /supported activities (Figure 6.2). 
The CMIS system is operated independently from the Navy Main- 
tenance Material Management System and is not designed to inter- 
face with NALDA or NALCOMIS. Update data submitted by user/ 
supported activities is provided to Grumman on specially designed 
formats/reports or in some cases on existing Navy report forms. 

Upon completion of data inputs/updates to the Master Data 
Base, a transfer routine immediately updates the Duplicate 
Data Base with the latest information. Data is contained 
or stored in the Master Data Base in a matrix format. Each 
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FIGURE 6.2 CMIS DATA BASE (REF-21) 





data address is composed of change identification numbers 
corresponding to the appropriate engineering change proposal 
and technical directive number. 

Once user access has been established through the log-on 
procedure and telenet system, two menu driven options are pro- 
vided; Report Output and Check Output. Selecting the Report 
Output option of CMIS provides the user access to sixty-four 
standard/catalogued reports designed to aid in change planning, 
identification, descriptions and overall change management. 

Table 6.2 provides a listing of available reports. Reports 
are selected by catalogue number and are formatted for high 
speed printers with wide carriages (210 characters) to provide 
maximum data. 

Selecting the Check Output option of CMIS provides the 
user with the capability to compare a given target baseline 
aircraft configuration with the "actual" configuration of 
another aircraft or group of aircraft. For example, assume 
a deployed F-14 squadron onboard an aircraft carrier in the 
Indian Ocean has lost an aircraft at sea and that an immediate 
replacement aircraft of identical configuration is required. 

The user would simply select the appropriate target baseline 
and input the bureau numbers of all potential replacement air- 
craft. The Check Output option of the CMIS system would iden- 
tify all differences between the target baseline and actual 
configuration of each potential replacement bureau number entered, 
thereby significantly simplifying the selection process. 
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TABLE 6.2 CMIS USER REPORTS [Ref. 21] 



* 



* 

* 



* 



* 



* 



* 



* 



* 

* 

* 



* 



ECPs IN PROCESS 

ECPs NOT REQUESTED 

ECPs REQUESTED BUT NOT SUBMITTED 

ECPs SUBMITTED BUT NOT APPROVED BY ACCB 

ACPs APPROVED BY ACCB — NO FORMAL AUTH RECEIVED 

ECPs WITH PRODUCTION AUTH AND NOT RET AUTH 

ECPs RETRO AUTH — ALL KITS NOT ORDERED 

PTR PROGRAM 

REDUCED-ECPS RET AUTH NOT ALL KITS ORDERED 
ECP SUMMARY 

ECP NUMBER/ STATUS SEARCH — QUERY 
CHANGE DESCRIPTION ECP — QUERY 
ACTIVE ECP STATUS SORTED BY ECP 
RM & S PROGRAM 

ACTIVE CHANGES BY CATEGORY — QUERY 
CHANGES BY RANK— QUERY 
ANCILLARY EQUIPMENT CHANGES 

SELECTED ANCILLARY EQUIPMENT CHANGES— QUERY 
TECH DIRECTIVE SUMMARY 

TECH DIRECTIVE NUMBER/ STATUS SEARCH — QUERY 
CHANGE DESCRIPTION TD — QUERY 
ACTIVE ISSUED TECH DIRECTIVES 

CONFIGURATION DIFFERENCES — ALL A/C VS BASELINE 
PRE DD250 TECH CIRECTIVE INCORPORATION 
TDs NOT ISSUED 

TITLE KEY WORK SEARCH— QUERY 
REMARKS KEY WORD SEARCH — QUERY 
SYSTEM STATUS SEARCH QUERY 
ACD NUMBER/ STATUS SEARCH — QUERY 
A/C 183 PLUS SDLM CHANGES (SDLM 1) 

BLOCK 95 PLUS SDLM CHANGES (SDLM 2) 

ACD SUMMARY 
CMIS WEEKLY NEWS 

SELECTED ECP EFFECTIVITY & INCORP STATUS 

SELECTED TD EFFECTIVITY & INCORP STATUS 

TIME COMPLIANCE REQUIREMENT TD INCORPORATION STATUS 

SEL TD NOT INC BY SEL BUNO 

SEL TD INC BY SEL BUNO 

TDs NOT INCORP BY SELECTED BUNO 

TDs INCORP BY SELECTED BUNO 

CONFIG DIFFERENCES — SELECTED BUNO VS BASELING — RQD TDS 

TD NIC & PAST RECISSION DATE BY SEL BUNO 

TCR TDS NOT INC BY SEL BUNO 

TD NIC BY SEL COMPLIANCE RQMT & SEL BUNO 

SEL TD NOT INC BY SEL SQUADRON 

TDs NOT INC WITHIN SEL SQUADRON (BUNO) 
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TABLE 6.2 (CONTINUED) 



TDs NOT INC WITHIN SEL SQUADRON (MATRIX) 

CONFIG DIFFS — WITHIN SEL SQUADRON — REQD TDS (MATRIX) 

CONFIG DIFFERENCES — SELECTED SQDN VS BASELINE— ROD TDS 

TDs NIC & PAST RECISSION DATE BY SEL SQUADRON 

TCR TDS NOT INC BY SEL SQUADRON 

SEL TD NOT INC BY SEL LOCATION 

TDs NOT INC BY SEL LOCATION (BUNO) 

TDs NOT INC WITHIN SEL LOCATION (MATRIX) 

CONFIG DIFFS — WITHIN SEL LOCATION — REQD TDS (MATRIX) 

TDs NIC & PAST RECISSION DATE BY SEL LOCATION 

TCR TDs NOT INC BY SEL LOCATION 

SEL TD NOT INC BY SEL SHOP NOS 

TDs NOT INC WITHIN SEL SHO NOS (MATRIX) 

TDs NIC & PAST RECISSION DATE BY SEL SHOP NOS 
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The CMIS system is an excellent configuration management 
tool for use at the functional wing or type commander level. 

It provides improved accuracy over the TDSA system and its 
counterpart, NALDA. This is reflected in Table 6.3 which pro- 
vides CMIS system accuracy figures as reported by Grumman Aero- 
space. Because CMIS does not depend on the Maintenance Data 
Collection System for input data, it tends to be fifteen to 
thirty days more current than TDSA or NALDA. 

The CMIS outputs are very readable and display ample infor- 
mation in a relatively small space. A sample output is provided 
in Figure 6.3. The number of formatted reports offered is 
larcre and varied enough to accommodate nearly all information 
requirements. The system has been successfully used at the 
Commander, Naval Air Force, U.S. Pacific Fleet Fighter Class 
Desk (type commander) to monitor and schedule F-14 depot main- 
tenance and deployment requirements up to five years in advance. 
CMIS successfully aggregates the configuration information 
required by mid- and upper-level managers for making aircraft 
assignment and technical directive incorporation decisions. 

On the other hand, CMIS has the capability of monitoring 
only those changes physically incorporated in the basic air- 
frame (airframe changes) . It cannot track avionics changes 
to weapon replaceable assemblies, powerplant changes to engines 
or aircrew system changes (e.g. ejection seats). CMIS is not 
designed to interface with NALDA or NALCOMIS, and it is cur- 
rently available for only Grumman products. It creates a 
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TABLE 6.3 CMIS DATA BASE AND CONTENT [Ref. 21] 



FIELD 


PERCENT OF 
DATA INPUT 


ACCURACY OF 
INPUT DATA 


ECP Number 


100 


100 


ECP Type 


100 


100 


ACD Number 


100 


100 


TD Number 


90 


100 


TD Category 


100 


75 


TD Issued 


100 


90 


Title 


100 


75 


Usage Code 


100 


100 


ECP Requested 


100 


100 


ECP Submitted 


100 


100 


ECP Planned/Actual FY Funding 


100 


100 


ECP Proposed Effectivity 


100 


100 


ECP Proposed Author izarion Data 


100 


100 


ACCB 


100 


100 


Production Authorization 


100 


100 


PRB Number 


100 


100 


First Production A/C 


100 


100 


Production Effectivity 


100 


100 


Block 


100 


100 


Retrofit Authorization 


100 


100 


First (Earliest) Retrofit A/C 


95 


90 


Retrofit Effectivity 


100 


90 


Pre DD-250 TD Incorporation A/C 


100 


100 


Kits Required 


100 


100 


Kits Ordered 


100 


100 


Projected TD Issuance Date 


100 


100 


Start TD Validation 


100 


100 


Complete TD Validation 


100 


100 


Start TD Verification 


100 


100 


Complete TD Verification 


100 


100 


Scheduled TD Issuance 


100 


100 


Submittal of TD to NATSF 


100 


100 


TD Issuance Date 


100 


100 


TD Rescission Date 


100 


100 


TD Compliance Requirement 


25 


100 


Last Event Code 


100 


100 


Last Event Date 


100 


100 


Next Event Code 


100 


100 


Next Event Date 


100 


100 
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TABLE 6.3 (Continued) 



FIELD 


PERCENT OF 
DATA INPUT 


ACCURACY OF 
INPUT DATA 


Text (Description) 


10 


100 


- Associated Changes 


10 


100 


- Remarks 


10 


100 


- Kit ID Numbers 


10 


100 


- Other 


0 


0 


WRA Part Number 


10 


100 


Retrofit Plan 


100 


100 


Maintenance Level 


100 


90 


Installation Manhours 


100 


90 


System Impacted 


100 


90 


Mean Flight Hours Between 


100 


100 


Failure Delta 


Maintenance Manhours per Flight 


100 


100 


Hour Delta 


Major Category of Change 


100 


100 


(Reliability, Performance) 


Rank Within Category 


100 


100 


Deconf igurable Change 


50 


25 


SDLM 1 Change 


100 


100 


SDL^l 2 Change 


100 


100 


Tech Problem Review Item 


100 


100 


Remarks 


100 


100 
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100 
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100 
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100 


100 
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100 


100 


Squadron Assignment 
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100 


Site Location 


100 
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Carrier Location 
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100 


WRA Change Incorporation Status 
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0 



83 



REPORT B6 CONFIGURATION HGHT INFORHATION 8Y8TEH <CHI8) PAGE 

F-M HANAOEHENT SUHHARY 

RUN HATE 02/23/82 HODEL TYPE F-14 



* 

* 

* 

z 

0 

H 

H 

U 

0 

J 

J 

u 

to 

> 

A 











m 












to 






O 










1 




2 


CO 




Q 


-J 


-i 










h- 








Ui 


2 






u 


u 




2 


<t 




2 


Ui 


Ui 






2 




2 


2 


2 




h- 


Ui 




< 


4C 


« 






2 




2 


2 


2 




<Z 


cri 00 


kO 




^k 


ro 


kC 


CM 


2 2 














•-« 2 














2 U 


o 


O 


O 


O 




a 


2 2 














< 






2 


2 


-J 


-J 


Ui -i 




X 






a 


a 


2 2 




o 


2 


2 


a 


2 




o 








2 






2 






O 


pv 














X. 




I— 










o 




►- 2 


ro 






n 


PI 




X Ui 


V 






\ 


X 




Ui > 


CM 






ri 


kO 




2 Ui 










o 






A 


a 


a 


a 


a 


a 




2 


2 


2 


2 


2 


2 



o* \n fv 
n 

o o o 

Ok (>. 

tn m m m 



O CD CM 
C4 CM 

o o o 
^ ^ ^ 
m m <n m 



w ^ m ^ 

^ ^ CM m m 

o o o ^ ^ 

o o Ok Ok ^ 

tn tn m m tn 



O CD ^ CM Ok 
rv <N 

o o o ^ ^ 

Ok ^ Ok Ok Ok 

m m to n m 



o 

o 

m 



n Ok m ^ 

^ n m ^ 

o o o ^ 

Ok Ok Ok Ok Ok ^ 

tn m m in in *o 

o 09 ^ (s Ok rv m 

^ CM ^ m 

o o o ^ 

Ok Ok Ok Ok Ok ^ 

m « m rj m ^ 'O 



m Ok in ^ 

<M w m 

o o o ^ 

Ok Ok Ok Ok Ok 

« m m m m 



O CD ^ CM Ok 
^ CM <N ^ 

o o o ^ 

^ Ok Ok Ok Ok 

m V) m n m 



u 

H 

<r 

Q 

Z 

0 

H 

CO 

CO 

H 

u 

u 

!L 

h 

co 

<. 

1 



u 

H 

z 

CO 

s 

a 

\- 

* 

* 

* 



o Ui 
2 ♦- 

2 2 
O O 

M 2 

h» OC 
< O 



Ok rv ^ Ok 
O ^ CM CM 

o o o 

Ok Ok Ok Ok Ok 

m m m m m 



Ok ^ ^ ^ ^ O 

o rj CM n 

o o o kO 

Ok Ok Ok Ok Ok Ok 

m m in m m m 



o> 

o 

o 

o> 

m 



Ok fv ^ ip« fv o O 

o C 4 D ^ m 
O o o ^ -<1 •• 

Ok Ok ^ Ok Ok Ok 
m « tn m m m 



Ok 

o 

o 

o> 

in 



Ok ^ ip^ rv o 

o ^ CM n m 

o o o ^ ^ kC 

Ok Ok Ok Ok Ok Ok 

n rj m m »n in 



U 


2 


2 


2 


2 


2 


2 


2 


2 


U. 


2 


U. 


2 


u. 




-i 


-) 


-) 


-) 


-) 


n 




2 




























2 




>- 












2 




2 








Ui 




2 


O 


X 






o 


U 


X 


2 


M 






2 


Ui 






2 








2 


h* 


2 








X 


2 


2 


2 


2 






1 


O 


Ui 




2 






2 


U 


2 


2 


< 






►— 


2 


Ui 




2 






2 


*ii4 


2 


2 


h- 


2 




Ui 


a 


X 


2 




2 




2 




2 


<t 


2 


« 




Ui 


H- 


< 


2 


3 


2 




-J 


« 


Ui 




2 


►- 




Ui 


Ui 


2 


p- 




2 






2 




Ui 


3> 






2 








2; 


A 




O 


Ui 




2 


O 


•m 




>» 


u 




1-4 


u 


2 


Ui 


Ui 


< 


►- 








-J 






2 


2 


o 


Ui 


h- 


2 


2 


Ui 


(J 






»>4 


O 


Ui 


2 


•-4 


a 






u 


2 




< 


3 


o 




o 




O 




u 


a 














«4 














2 




PO 


^ ' 


O 




»k 


PI 




fx 


Ok 


Ok 




n 


O 


2 


M 




kO 




kO 


Pk 


U 














UJ 














o 


«» 


«» 


m 


«» 


«» 


«» 
















2 


< 










2 


•■14 


fx 




fx 






‘V4 


a 


O 


o 


m 




ipi» 


o> 




kO 




in 


kO 


fx 


o 


s 












m 


u 


u 


u 


u 


u 


U 


2 


Ui 


< 


u 


2 


2 




Ui 




< 


< 


< 


< 


< 


•i 


u 


2 


-i 


2 


2 







34 



FIGURE 6.3 SAMPLE GMIS OUTPUT [REF. 21] 



duplicate configuration status accounting data base which must 
be maintained and verified against the TDSA data base.. At 
the present time, the maintenance of that data base is done 
by Grumman Aerospace through a contract with the Navy. This 
arrangement fails to provide a timely method for collecting 
data from and supporting deployed squadrons and carrier air 
wing staffs, since telenet is not available to deployed car- 
rier based units. 

CMIS is an effective contractor-developed, contractor-run 
system that is valuable to Navy managers. However, in order 
to fully benefit from CMIS, the Navy must develop the capa- 
bility to maintain and update the system within its own config- 
uration management information system structure. 

D. ENGINE COMPOSITION TRACKING SYSTEM (ECOMTRAK) 

Engine management presents numerous unique configuration 
related problems. For instance during engine build-up, fol- 
lowing rework or repair, engine life-limited components must 
be matched with other components having similar "life remain- 
ing" in order to optimize overall engine service life. Addi- 
tionally, all components installed must be matched for 
configuration compatibility. All applicable unincorporated 
technical directives must be identified and incorporated during 
each overhaul or repair, as it is not economically or opera- 
tionally sound to remove engines from operational or nonoper- 
ational aircraft solely for technical directive incorporation. 
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In many cases the incorporation of a technical directive alters 
a component's "service life remaining" which in turn might 
alter the engine's service life. Finally, engine components 
are tracked by their assigned serial numbers and by the engine 
serial number in which they are installed. On most jet en- 
gines, the serial number plate is attached to the main gear 
box. If this gear box is replaced and the serial number plate 
is not switched (a common occurrence) , the configuration sta- 
tus information of the installed engine components can become 
quickly confused or invalid. 

Because the NAVAIR Maintenance Material Management system, 
of which the TDSA system is a part, does not manage these com- 
plex problems, the Engine Analytical Maintenance Program was 
developed to identify those actions required to develop and 
maintain engine composition/configuration tracking. Addition- 
ally it identifies those engine management functions to be 
performed to support reliability centered maintenance . In 
conjunction with the Engine Analytical Maintenance Program, 
the Automated Engine Composition Tracking System (ECOMTRAK) 
is being developed to provide on-line information necessary 
to manage aircraft engine configuration and maintenance. 

When implemented, ECOMTRAK is planned to be fully compat- 
ible with NALCOMIS and will extract all input data'from the 
Maintenance Data Collection System of the Maintenance Material 
Management System. The implementation of ECOMTRAK for each 
specific engine requires the performance of the following 
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Phase II 
Phase III 

Phase IIIA 
Phase IV 



sequential events by aircraft engine support and management 
activity commands: 

Phase I Selection of items to be tracked 

Tracked item data input 

Engine composition data collection and 
input and ECOMTRAK file maintenance 
Depot implementation 
Engine asset management 
The ECOMTRAK System is currently being developed and main- 
tained by NAVAIR through contractor support. When fully imple- 
mented and properly maintained, ECOMTRAK will provide real 
time engine management information for use as follows: 

1 . To project spare part support requirements 

To forecast intermediate and depot engine workload 
To establish depth and scope of engine repair 
To assist fleet operators with management of component 
life limits 

To assist in establishment of fixed allowance lists 
To determine the impact of technical directives 
To determine the impact of component life limits 
None of the above tasks can be effectively accomplished without 
the availability of up-to-date, accurate comprehensive engine 
configuration information. 

Within ECOMTRAK, reliability-centered maintenance analysis 
logic is used to determine which components to track. Other 
items being scheduled for tracking include high value, long 
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procurement lead time items and items with technical directive 
or configuration impact. Both repairable and consumable items 
are being identified for tracking by the application of Mili- 
tary Standard 266 Reliability Centered Maintenance logic. 

Data sources being utilized for ECOMTRAK file construction 
include maintenance plans, illustrated parts breakdowns, tech- 
nical directives, engineering change proposals, local instruc- 
tions, engine logbooks and planned maintenance requirements 
for each specific type/model/series engine. After initial 
data entry, data base maintenance is accomplished at the orga- 
nizational and intermediate levels by continuous entry of main- 
tenance actions (including technical directive incorporation) , 
flight activity data, custody change data and depot maintenance 
data. A visual representation of the update process is depicted 
in Figure 6.4. 

Unlike most of the existing configuration management pro- 
grams in the Navy, ECOMTRAK is not a stand alone system. It 
has been designed to interface directly with the TDSA system 
and NALDA and is completely compatible with NALCOMIS. When 
fully implemented, ECOMTRAK is designed to; 

1. Track all engine parts by serial number providing 
location and condition 

2. Generate reports that provide data on available parts 
for best match engine build-up 

3. Automate engine build-up data collection 
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4. Automatically screen all data for correct application 

5. Automatically produce all engine logbook records 

6. Automatically update the TDSA engine data bank 

7. Provide current technical directive Lists 02 and 04 
for each processed engine 

8. Produce a scrap parts file 

9. Automate parts ordering 

10. Produce preformatted reports identified in Table 6.4. 

TABLE 6.4 ECOMTRAK REPORTS 

* ENGINE REPORTS 

* Engine Status Report 

* Critical Components Tracking Report 

* Engine Associated Critical Component Status Report 

* Engine Hard Time Report 

* Fleet Component Rejections Projected Report 

Although ECOMTRAK is still in the development phase, it 
has the potential to significantly enhance engine configuration 
management by providing engine /component serial number tracking. 
With the advent of ECOMTRAK, all of the required data on any 
given engine will be available in an accurate, accessible for- 
mat at the management level where it is required. 
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E. PORTABLE LOGISTIC SYSTEM (PLS) 

The Portable Logistic System (PLS) is a Commander, Naval 
Air Force, U.S. Atlantic Fleet (CNAL) initiative designed to 
provide an improved aircraft maintenance management informa- 
tion system at the squadron level. It is a functional exten- 
sion of and logical outgrowth from several existing automated 
systems — the Aviation Training Support System, the Resource, 
Configuration and Scheduling Subsystem and the Comprehensive 
Asset Management System [Ref. 22]. The Aviation Training Sup- 
port System, which is designed and installed as a dedicated 
training system, contains a subsystem defined as Resource, 
Configuration and Scheduling which was designed to match air- 
crew and syllabus training assignments with a correctly con- 
figured aircraft: The Comprehensive Asset Management System 

was developed from the Resource, Configuration and Scheduling 
subsystem to maintain configuration data on and status of air- 
craft, engines and other selected aeronautical equipment. 

PLS is designed to be a distributed processing system with- 
in functional/carrier air wing organizations. At each geographic 
location, both ashore and afloat, PLS provides communication 
facilities for remote data entry and data query. Squadrons 
communicate via cable/f iberoptics with colocated functional/ 
carrier air wings. Although PLS provides for remote access 
capability by higher level managers such as Commander, Naval 
Air Force, U.S. Atlantic Fleet when both activities are shore- 
based, communication between ashore and afloat units is restricted. 
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The distributed PLS system is configured with minicomputer 
central processing units, mass storage and input/output de- 
vices. A typical squadron allocation of hardware is depicted 
in Table 6.5, and a typical functional wing and carrier air- 
wing hardware allocation is tabulated in Table 6.6. 

Each squadron system supports the functional requirements 
of squadron users. Certain data are provided on a routine 
basis to the functional wing system ashore or carrier airwing 
system afloat depending on squardron location. The wings then 
exchange data between carrier and shore location for updating 
specific aircraft and personnel training data bases. This 
distributed design concept is depicted in Figure 6.5. PLS 
fundamentally uses a two level hierarchical design configura- 
tion. The design is hierarchical in that data is originated 
at the squadron and relayed to the wing system for the pur- 
pose of data backup and information exchange. The distributed 
feature of PLS allows squadron systems to function even in 
the event of a functional/carrier air wing system failure. 

Because PLS is not compatible with NALCOMIS, its expected 
life will depend on NALCOMIS implementation. PLS will be ter- 
minated when NALCOMIS becomes operational at each PLS site. 
Although not specifically planned within the PLS concept, data 
can be supplied directly to systems such as TDSA or the Engine 
Analytical Maintenance Program. 
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TABLE 6.5 PLS SQUADRON HARDWARE ALLOCATION 



QUANTITY 



1 

8 

1 

2 

2 

1 



DESCRIPTION 

PDP 11/23 CPU, 256 KB Memory 
1 MB Floppy Disk 

Serial Communication Ports 

27 MB Winchester Disk Drive and 
Controller 

Hard Copy Terminals 

CRT Terminals 

Uninterruptable Power Supply 
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TABLE 6.6 FUNCTIONAL/ CARRIER AIRWING HARDWARE ALLOCATION 



QUANTITY 



1 

16 

1 

8 

4 

4 

1 

1 

1 



DESCRIPTION 

PDP 11/23 CPU, 256 KB Line Clock 
1 MB Floppy Disk 

Serial Communication Ports 

134 MB Winchester Disk Drive and 
Controller 

Optical Link Drivers 
Hard Copy Terminals 
CRT Terminals 

Magnetic Tape Drive and Controller 
Uninterruptable Power Supply 
300 LPM Printer and Controller 
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SHORE STATION CARRIER BASED 
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FIGURE 6.5 distributed PLS 

(REF. 22) 






Input data to PLS include: the Naval Aircraft Flight 
Record (OPNAV 3700/2), X-Ray (OPNAV 5442-1), Engine Trans- 
action Report, Visual Information Display System/Maintenance 
Action Form, Aircrew Debrief Forms and Personnel Record Forms. 

As indicated in Figure 6.6, these inputs will automatically 
produce historical files and the following standard outputs: 
Technical Directive Catalog, Technical Directive Incorporation 
Status Report, Aircraft Transaction X-Ray Message, Engine Trans- 
action Report Message, End of Operating Quarter Report, Aircraft 
Accounting Record, Record "A" Report, Daily Flight Time Report, 
Personnel Summaries and Aircrew Training Status. 

The technical directive catalog output of the PLS system 
is produced automatically at the end of each month or upon 
query. This report summarizes all of the significant data 
contained in the technical directive source document (Visual 
Information Display System/Maintenance Action Form) . Addition- 
ally, it specifically describes the status and effectivity 
of each technical directive issued for each type of aircraft, 
engine or aeronautical equipment. The Configured Item Status 
output of the PLS system is generated daily, upon query, or 
as directed. It is specifically designed to provide the main- 
tenance manager with real time information regarding config- 
uration impacts and removal schedules. This report contains 
status information on each individual serialized component 
installed in assigned aircraft and engines. The Technical 
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Directive Incorporation Status output is produced monthly or 
upon query. It provides a summary of the status of incorpor- 
ated/not incorporated technical directives in each assigned 
aircraft or engine. This output can be utilized to verify 
the TDSA Lists 02 and 04 on a real time basis. Although addi- 
tional PLS outputs provide significant management information, 
they are not directly related to configuration status account- 
ing and are therefore not discussed in this thesis. 

One advantage to organizational level management is that 
PLS is a bottom-up system. It was designed at the working 
level which is in sharp contrast to most other systems, inclu- 
ding NALCOMIS, which have been designed from the top down. 

It is the authors' opinion that top-down systems are frequently 
designed around reporting requirements rather than around or- 
ganizational level management information needs. PLS provides 
both real-time configuration management information and summary 
data formatted to meet higher level information and report 
requirements . 

PLS is capable of maintaining configuration status account- 
ing data only on technical directives physically incorporated 
and documented by the reporting custodian (squadron) . Although 
PLS provides serial number component control, it is deficient 
as a result of its inability to track technical directives 
incorporated in avionics, engines or other aeronautical equip- 
ment by intermediate or depot activities. 
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The fact that PLS is neither a NAVAIR-wide system nor in- 
teractive with the NAVAIR prescribed systems is a major draw- 
back. Specifically in the area of configuration status 
accounting, PLS does nothing more than duplicate and compile 
the data currently available in the Maintenance Data Collec- 
tion System. Because PLS data entry requires transcription 
of the manually originated maintenance data entry form (Visual 
Information Display System/Maintenance Action Form) , the level 
of system accuracy will not be significantly improved. How- 
ever, the information will be more current, as data entry is 
done at the squadron level, rather than at a remotely located 
data processing facility. 

F. SUMMARY 

In this chapter four of the many independently developed 
configuration status accounting/maintenance management infor- 
mation systems have been reviewed. VAMP was specifically de- 
veloped for use at the intermediate level of maintenance to 
manage only VAST supported . avionics components. CMIS, devel- 
oped by Grumman Aerospace, applies to only F-14 aircraft spe- 
cific modifications accomplished at either the organizational 
or depot levels of maintenance. PLS, a CNAL initiative, is 
being developed to provide improved maintenance management/ 
configuration status accounting information at the organiza- 
tional and functional/carrier air wing levels. With regard 
to configuration documentation, PLS only accounts for modifications 
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incorporated at the organizational and depot levels of main- 
tenance. ECOMTRAK is being implemented to provide on-line 
information necessary to manage engine configuration and main- 
tenance at the organizational, intermediate and depot levels. 

Of these four systems, only VAMP and ECOMTRAK are designed 
to be compatible with NALCOMIS and NALDA. CMIS and PLS , al- 
though valuable tools, duplicate TDSA and each other. All 
four systems reviewed in this work duplicate the data entry 
requirements of the TDSA System. With the exception of ECOMTRAK, 
none of the systems are designed to support serial number 
tracking of components as they migrate through the three levels 
of maintenance. Additionally CMIS and PLS do not track the 
configuration status of aircraft installed engines, weapon 
relaceable assemblies and ejection seats. 

The major advantages all four systems have over the TDSA 
and NALDA systems are improved accuracy, timeliness and acces- 
sibility of maintenance management information necessary to 
support the aviation maintenance effort. The major disadvan- 
tage of local systems in general is the lack of NAVAIR system 
standardization and integration. Consequently, logistic sup- 
port based on the information provided by these systems is 
less than optimum. 
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VII. NAVAL AVIATION LOGISTICS COMMAND MANAGEMENT 
INFORMATION SYSTEM (NALCOMIS) — THE FUTURE 

A. HISTORY 

The proliferation, redundancy and inconsistency of exist- 
ing management information systems has been a topic of concern 
in the Navy for several years. Rapidly advancing technology 
has greatly increased the complexity of Naval aircraft and 
the number of actions required to maintain them. As a result, 
the volume of information needed to forecast, schedule, moni- 
tor and report maintenance actions has also increased. The 
Naval Aviation Maintenance and Material Management System was 
devised and implemented in 1965 to collect and process this 
information. Constrained by the automated data processing 
technology of the time, it is only a partially automated sys- 
tem. Data is originated manually and then later keypunched 
into a computer. The increased volume of transactions and 
the transition from manual collection and input to automated 
compilation and storage has introduced problems that open the 
system to skepticism and distrust by the users. 

In an attempt to improve carrier aircraft readiness, the 
Chief of Naval Operations established in 1970 the Carrier Air- 
craft Maintenance Support Improvement (CAMSI) Project. With 
regard to shipboard aircraft maintenance and support management, 
the CAMSI findings indicated that an acceptable level of effi- 
ciency could be obtained in the most practical and cost effective 
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manner through the improved use of automated data processing 
equipment [Ref. 23] . 

In response to the CAMSI findings, NAVAIR and the Naval 
Supply Systems Command initiated a joint project in 1972 titled 
Shipboard Aviation Command Management Information System (SACOMIS) . 
The purpose of the SACOMIS project was to design and develop 
an automated management information system, and the SACOMIS 
Automated Data Systems plan concept was approved by the Chief 
of Naval Operations in 1974. Also in that year, the Chief 
of Naval Operations directed that SACOMIS additionally include 
Naval Air Stations, Marine Corps Air Stations, Marine Aircraft 
Groups, Helicopter Aircraft Carriers and Helicopter Assault 
Aircraft Carriers. At this time the title of the program was 
changed from SACOMIS to NALCOMIS. Thus, what started as a 
carrier aircraft specific project was expanded to include all 
of Naval and Marine Corps aircraft. It is intended to be an 
effective, real time, automated, user-oriented system for avia- 
tion maintenance and logistic support personnel. Its purpose 
is "to improve operational readiness of Navy and Marine Corps 
aviation units through improvements, via automation, of air- 
craft maintenance and supply management effectiveness." [Ref. 

15] 

NALCOMIS is being developed using a modular approach with 
the Module I Automated Data Systems Plan submitted in October 
1976. This module was certified in 1977 and applied to only 



102 



the Organizational Maintenance Activity (OMA) , Intermediate 
Maintenance Activity (IMA) and Supply Support Center (SSC) 
areas of Naval and Marine Corps aviation. The following dis- 
cussion of NALCOMIS deals with NALCOMIS Module I. 

B. NALCOMIS SYSTEM DESIGN 

NALCOMIS was initially designed as a site-oriented cen- 
tralized system in which each naval air station, aircraft car- 
rier, etc. would have a central processor and a single integrated 
data base. However, this concept proved to be unsatisfactory 
for supporting the requirements of Marine Corps and Navy users. 
Consequently, it was changed to an Independent /Distributive 
Data Base design. It is currently comprised of three Indepen- 
dent Functional Processes (IFPs) , one each for the OMA (IFP-A) , 
IMA (IFP-B) and SSC (IFP-C) . The accompanying hardware consists 
of an independent Remote Peripheral Subsystem Processor located 
at each OMA and at the IMA. The remote processor of each unit 
holds the data base unique to that unit. A central processor 
holds the Common Data Base (data common to or required by all 
users) . There is also a networking provision that allows access 
for authorized users to data in the distributed data bases 
and the Common Data Base. Required interfaces to provide data 
to external systems are being provided for all three IFPs. 
Interface with the Naval Aviation Maintenance and Material 
Management System is currently planned. 
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The change to the Independent /Distributed Data Base design 
offers several advantages over the original centralized design 
with regard to satisfying the needs of the users. It allows 
the system to be implemented on a squadron-by-squadron basis 
without interfering with deployment schedules and other require- 
ments. With each unit possessing its own remote processor 
and storing its own data base, the response time from the sys- 
tem is optimized. The distributed remote processors allow 
units to deploy and still retain their automated organizational 
level capability, a critical requirement for Navy and Marine 
Corps units. Failure of one component of the system does not 
render the entire system unusable. This would not have been 
possible under the central processor concept. 

C. NALCOMIS PROVISIONS FOR CONFIGURATION STATUS ACCOUNTING 
In general, NALCOMIS automates the manual Visual Informa- 
tion Display System/Maintenance Action Form which is currently 
used for recording, controlling and monitoring aircraft main- 
tenance. It also collects, processes and stores flight acti- 
vity data and personnel management data. In addition, IFP-B 
(IMA) provides repairables management capabilities and IFP-C 
(SSC) includes repairables management and requisition process- 
ing functions. All IFPs include a Configuration Status Account- 
ing Subsystem. To date, IFP-A (OMA) is the only Independent 
Functional Process completed, and it is being tested at one 
Naval Air Station and one Marine Corps Air Station. Consequently 



104 



the documentation for IFP-A Configuration Status Accounting 
Subsystem is more concise and detailed than that for either 
IFP-B or IFP-C. 

1. IFP-A 

The Configuration Status Accounting Subsystem of 
IFP-A provides: 

...those functions required to establish the aircraft 
configuration record and to maintain configuration of 
the engines and components that make up aircraft or 
Support Equipment (SE) and will include capability for 
serial number tracking and Technical Directive (TD) 
management. [Ref. 24] 

Those configuration items that require serial number tracking 
as directed by higher authority can be accommodated under IFP-A. 
In addition, each command may select and track additional items 
through this subsystem. 

The three main divisions of this subsystem are Engine 
Configuration, Component Configuration and Technical Directive 
Management. The Engine Configuration section tracks specific 
engines and/or engine module serial numbers for installed and 
uninstalled engines. It also maintains aeronautical equipment 
service record information for engines and engine modules. 

The Component Configuration section tracks aircraft, 
support equipment, and engine components by serial number. 

If the components are controlled by individual cards in the 
engine logbook, they are specially flagged, since additional 
information is required in the NALCOMIS record. 
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The Technical Directive Management section tracks in- 
formation relating to technical directives for aircraft, support 
equipment, engines or components. It indicates applicable 
technical directives for specific bureau and/or serial numbers 
and the technical directive incorporation status. Upon tech- 
nical directive incorporation, a notice is printed for main- 
tenance control to make the required logbook entries. 

Data for this subsystem is initially established through 
a manual configuration update menu. Actual aircraft config- 
uration, current technical directive applicability, engine 
configuration, engine installation status, and component con- 
figuration are initially entered through this option. Addi- 
tionally, this option is used to add or delete records or 
aircraft/engines/components that are received or transferred. 

There is also a provision for an automated configuration 
update. This portion of the subsystem interacts with the Main- 
tenance Activity Subsystem (automated Visual Information Display 
System/Maintenance Action Form) to automatically update esta- 
blished configuration records. This automated update occurs 
when maintenance actions affecting configuration are performed, 
such as technical directive incorporation or equipment installa- 
tion and removal. The automated configuration update encompasses 
engines, engine components, aircraft and support equipment. 

In addition, the technical directive update section provides 
a notice to maintenance control if the incorporation of a tech- 
nical directive requires a part number change. 
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Also included in the Configuration Status Accounting 
Subsystem of IFP-A is a configuration interchangeability/ 
compatibility section. For components whose configuration 
is maintained through this subsystem, a listing of those com- 
ponents which may or may not be interchangeable can be manually 
recorded by Federal Supply Code or Manufacturer /Part Number. 

Configuration information may be retrieved in the form 
of inquiries and reports. The inquiries available are: 

1. Engine Serial Number Location 

2 . Component Configuration Location 

3. Technical Directives 

4 . Interchangeability/ Compatibility 

The first two options provide location information for specific 
engine or component serial numbers, i.e. where an engine or 
component is installed. This information may also be obtained 
for all engines assigned to an organization. The Technical 
Directive inquiry gives technical directive information for 
a specific technical directive code and a specific aircraft/ 
engine /component . The fourth inquiry lists interchangeability/ 
compatibility information for a specific Federal Supply Code 
or Manufacturer /Part Number. 

The hard copy reports available are as follows: 

1. Aircraft Configuration (including engines and components) 
for a specific type /model /series or bureau number or for all 
aircraft within a squadron 
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2. Engine Configuration (including 'modules and components) 
for a specific type /model /series or serial number or for all 
engines held by a squadron 

3. Technical Directive Configuration for a given technical 
directive code and number. This report lists the technical 
directive's applicability to squadron held items and whether 

or not the technical directive has been incorporated in those 
items 

4. Component Location of a specific Federal Supply Code 
or Manufacturer /Part Number for the bureau number plus any 
interchangeable parts listed for that number 

The IFP-A Configuration Status Accounting Subsystem 
concept established a preferred configuration for each air- 
craft, engine and component. The actual configuration for 
a particular aircraft, engine and/or component can then be 
compared to its preferred configuration and discrepancies re- 
ported. The preferred or optimum configuration profiles are 
created, revised, or deleted in the Manual Configuration Update 
portion of the subsystem. 

2 . IFP-B and IFP-C 

As stated above, the IFP-B and IFP-C portions of NALCOMIS 
are not complete, and the documentation concerning the Config- 
uration Status Accounting capabilities is not yet detailed. 

In general, the IFP-B is intended to have the IFP-A capabilities 
for engines, components and support equipment as well as the 
ability to track technical directives. The IFP-C is intended 
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to have only the inquiry and report generating capability for 
Configuration Status Accounting and only when the IFP-A and 
IFP-B functions are available. 

D. COtIFIGURATION STATUS ACCOUNTING IMPROVEMENTS 

NALCOMIS offers many improvements to the current config- 
uration status accounting system. It gives the organizational 
and intermediate maintenance levels a real-time interactive 
management information system for monitoring actual aircraft/ 
engine /support equipment configuration and technical directive 
incorporation status. When provided with upline reporting 
capability through the Naval Aviation Maintenance and Material 
Management System interface, NALCOMIS in conjunction with NALDA 
corrects many of the problems that invite criticism of the 
current system. 

Data accuracy within NALCOMIS is improved for several 
reasons . 

1. Visual Information Display /Maintenance Action Forms 
are no longer hand written, and their transcription via key 
punch is no longer required. 

2. The data within each remote processor is self verified 
and updated. Therefore, incompatible maintenance action in- 
formation can not be entered. Once current data is entered 

in one area it is updated throughout the data base. 

3. Fewer individuals originate the information and enter 
it into the system. 
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4. Reconciliation of hand written data with machine gen- 
erated reports is not required. 

5. Transactions with missing data (such as technical di- 
rective incorporation manhours) are not accepted. 

6. Misplaced and lost configuration lists are not a pro- 
blem, as new lists can be generated as needed. 

It is anticipated that there will be improved standardiza- 
tion of all configuration information, especially across func- 
tional wings, type commands and carrier air wings. The depth 
and organization of configuration data is consistent, allowing 
mid- level and upper-level managers to make comparisons and 
compilations. Serial number tracking of components, which 
is presently done manually through a varying number of local 
systems (if it is done at all) , is performed in a structured 
and manageable form. 

Management of technical directive change kits is greatly 
improved. Kit managers have access to more up-to-date, com- 
plete information concerning kit requirements, issue and in- 
corporation. This in turn gives them more control over kit 
procurement, redistribution, cannibalization and disposal. 

Significant improvements can be expected in aircraft/ 
engine /support equipment performance and safety as the system 
develops. An improved management information system results 
in more accurate weight and balance data. The movement of 
components from one aircraft or engine to another can be more 
accurately tracked. With up-to-date, accurate information 
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there is less chance of installing incompatible components. 
Technical directive change requirements are more readily iden- 
tifiable, allowing units to take advantage of the safety and 
performance improvements which were the bases for the changes. 

As a result, technical directive incorporation brings about 
improved design, stability, control and mission capability. 

Implementation of NALCOMIS is expected to improve the lo- 
gistic supportability of the aircraft and supporting equipment. 
If the configuration of these items can be accurately ascer- 
tained, spare parts and material support can be better planned 
and implemented. This in turn allows the -proper provisioning 
in both the range and depth of spare parts required and iden- 
tifies those parts that may be purged to open up needed storage 
space and reduce inventory holding costs. In addition, main- 
tenance technician training can be correctly scheduled based 
on the actual equipment to be supported. Improved provisioning 

and training contributes to the improved safety and performance 
discussed above. 

E. CONFIGURATION STATUS ACCOUNTING DEFICIENCIES 

Even with the improvements NALCOMIS brings to configuration 
status accounting, some problem areas will remain. For example, 
logbook entries will still be accomplished manually with the 
resulting possibilities for errors. Consequently, the require- 
ment for verification between the logbook entries and the con- 
figuration information held by NALCOMIS will still exist. A 
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provision for an automatically printed logbook page would 
greatly enhance the system. 

There is not at present an Independent Functional Process 
planned for use at the functional wing, type commander or car- 
rier airwing staff levels. As the distributed system is cur- 
rently designed, configuration information across an airwing 
would be obtained from each squadron remote processor and man- 
ually aggregated. A staff level process for extracting and 
sorting this information is required to convey the data to 
upper management levels. In addition, staffs require a long 
range configuration planning capability, such as that currently 
used in conjunction with the Grumman Configuration Management 
Information System. NALCOMIS contains information about air- 
craft that is essential for planning overhaul and deployment 
assignments. Such information should be made available to 
those managers who are making these decisions. 

The distributed system allows an air station or carrier 
to continue operation in the event of a remote processor fail- 
ure. However, backup capability for a squadron should its 
remote processor fail must be addressed. It is unacceptable 
for maintenance operations to be halted for even short periods 
due to the inaccessibility of the information held by NALCOMIS, 
and manual backup would systems only defeat the purpose of 
NALCOMIS. Redundant hardware and spare components should be 
provided within NALCOMIS (especially in remote location) to 
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allow units to continue operation while inoperative hardware 
is being repaired. 

At the present time, NALDA provides information on only 
airframe and engine technical directive changes. This capa- 
bility must be expanded to include other changes such as 
avionics, aircrew and support equipment. 

Finally, the implementation of NALCOMIS must be carefully 
planned. If the current configuration data base is used in 
its present form, the system will be inaccurate from the start. 
Significant time and effort will be required to ensure that 
technical directive status accounting records are accurate 
and up to date with regard to the actual configuration of the 
aircraft . 
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VIII. CONCLUSIONS AND RECOMMENDATIONS 



A. CONCLUSIONS 

Based on configuration status accounting research conducted 
for this thesis, the following conclusions are made: 

1 . The existing TDSA and NALDA systems lack the means 
to identify, collect, sort, collate and communicate config- 
uration status accounting data in a timely and accurate manner. 

2. Local systems developed as a result of budgetary lim- 
itations and TDSA/NALDA system deficiencies provide significant- 
ly improved configuration status accounting information but 
only for their specific application. 

3. The proliferation of locally developed systems lack 
overall coordination, integration and standardization. On 
the whole this decreases NAVAIR logistic support and mainte- 
nance management effectiveness. 

4. NALCOMIS, with modification, has the potential to satis- 
fy NAVAIR configuration status accounting management information 
needs . 

B . RECOMMEND AT IONS 

Based on the above conclusions, the following recommendations 
are made : 

1. Expedite, to the maximum extent possible, development 
and full implementation of NALCOMIS. Additionally, include 
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within NALCOMIS provisions for upline reporting to functional 
wings, carrier air wings and type commanders. 

2. Develop as a basic aviation maintenance data collec- 
tion goal, one-time entry of each data element for use by all 
aircraft maintenance management information systems. 

3. Expand NALDA to include all technical directive change 
categories and comprehensive component serial number tracking. 
Provide additional NALDA terminals at all user sites. As an 
interim measure, improve TDSA timeliness by increasing the 
distribution frequency of Lists 02 and 04. 

4 . Authorize the continued operation of all existing local 
systems, restricting investment in system improvement, until 
NALCOMIS has been implemented fully. 

5. Develop a NAVAIR committee to review and approve emer- 
gent and existing management information systems to ensure 
integration with NALCOMIS. 

6. Initiate action to improve the accuracy of the TDSA/ 
NALDA data base by a) reducing errors during Visual Information 
Display /Maintenance Action Form transcription and b) enforcing 
depot level technical directive verifications conducted during 
rework . 

7. Increase the utilization of ECOMTRAK and VAMP to cover 
all intermediate and depot avionics and engine types. 
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APPENDIX A 
ACRONYMS LIST 



AIMSO 


Aircraft Intermediate Maintenance Support Office 


CAMS I 


Carrier Aircraft Maintenance Support Improvement 


Cl 


Configuration Item 


CMC 


Commandant of the Marine Corps 


CMIS 


Configuration Management Information System 


CNAL 


Commander, Naval Air Force, U.S. Atlantic Fleet 


CNAP 


Coitunander, Naval Air Force, U.S. Pacific Fleet 


DOD 


Department of Defense 


ECOMTRAK 


Engine Composition Tracking 


I 


Intermediate Maintenance Level 


IFP 


Independent Functional Process 


ILS 


Integrated Logistics Support 


IMA 


Intermediate Maintenance Activity 


MAG 


Marine Air Group 


NALC 


Naval Aviation Logistics Command 


NALCOMIS 


Naval Aviation Logistics Command Management 



Information System 



NALDA 


Naval Aviation Logistic Data Analysis 


NAVAIR 


Naval Air Systems Command 


NAVMAT 


Naval Material Command 


NAVMATINST 


Naval Material Command Instruction 


NAVSUP 


Naval Supply Systems Command 


0 


Organizational Maintenance Level 
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OMA 


Organized Maintenance Activity 


OPNAV 


Chief of Naval Operations 


PLS 


Portable Logistics Support 


SACOMIS 


Shipboard Aviation Command Management 



Information System 



SRA 


Shop Replaceable Assembly 


SSC 


Supply Support Center 


TDSA 


Technical Directive Status Accounting 


TYCOM 


Type Commander 


VAMP 


VAST Automated Management Program 


VAST 


Versatile Avionics Shop Test 


WRA 


Weapon Replaceable Assembly 
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APPENDIX B 
GLOSSARY 



1. AVIATION MAINTENANCE AND MATERIAL MANAGEMENT SYSTEM (3-M) ; 

A subsystem of the Naval Aviation Maintenance Program 
designed for the purpose of providing maintenance data 
collection, manhour accounting and aircraft accounting. 

2. ALLOCATED BASELINE : The formally designated allocated 

configuration identification fixed as a product of the 
demonstration and validation phase of the life cycle. 

3. AUDIT ; To inspect records and procedures. 

4. BASELINE : An approved reference point for control of 

future changes to a product's performance, construction 
and design. 

5. CARRIER AIR WING ; The staff directly responsible for 
providing operational, maintenance and administrative 
support to all assigned squadrons located onboard the 
same aircraft carrier. 

6. CHANGE ; Within the context of configuration control, 

a formally recognized revision to a specified and docu- 
mented Navy material requirement. Includes design 
changes, engineering changes, field changes, technical 
directive changes, changes in specifications or other 
related requirements . 

7. CHANGE IDENTIFICATION NUMBER ; A number assigned to a 
data package defining an equipment engineering change. 

It is used to control, sequence and account for pro- 
duction, implementation, and retrofit actions relating 
to the change . 

8. COMPONENT ; A part, subassembly, assembly or combination 
of these items joined together to perform a function. 

9. CONFIGURATION ; The functional and/or physical charac- 
teristics of hardware /software as set forth in technical 
documentation and achieved in a product. 

10. CONFIGURATION ITEM (Cl) ; An aggregation of hardware/ 
software, or any of its discrete portions, which satis- 
fies an end use function and is designated by the Govern- 
ment for configuration management. CIs may vary widely 

in complexity, size, and type, from an aircraft, electronic 
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or ship system to a test meter or round of ammunition. 

During development and initial production, CIs are only 
those specification items that are referenced directly 
in a contract (or an equivalent in-house agreement) . 

During the operation and maintenance period, any repair- 
able item designated for separate procurement is a con- 
figuration item. 

11. CONFIGURATION MANAGEMENT ; A discipline applying tech- 
nical and administrative direction and surveillance to 
(1) identify and document the functional and physical 
characteristics of a configuration item, (2) control 
changes to those characteristics, and (3) record and 
report change processing and the implementation status 
of approved changes. 

12. CONFIGURATION STATUS ACCOUNTING (CSA) ; The recording 
and reporting of an approved configuration identifica- 
tion, and the status of proposed changes to the approved 
configuration and implementation status of approved 
changes . 

13. CONFIGURATION CHANGE ; A general term which signifies 
that the configuration of an item has been or will be 
changed through the configuration control process. 

14. DEPOT LEVEL ; The top level of the three levels of 
maintenance. Generally considered industrial in nature. 

15. ENGINEERING CHANGE PROPOSAL ; A document that proposes 
change to a Navy material item in accordance with appli- 
cable bulletins, regulations, standards and other directives. 

16. EQUIPMENT ; An item designed and built to perform a spe- 
cific function as a self-contained unit or to perform a 
function in conjunction with other units. It is the same 
as a product. 

17. FUNCTIONAL BASELINE : The functional configuration iden- 

tification initially approved by the customer. 

18. FUNCTIONAL WING ; The staff directly responsible for pro- 
viding operational, maintenance, and administrative support 
to similar aircraft squadrons located in the same geographic 
area . 

19. INTERFACE ; A region common to two or more elements, sys- 
tems, projects or programs, characterized by mutual phy- 
sical, functional, and/or procedural properties. 
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20. INTEGRATED LOGISTIC SUPPORT (ILS) ; A composite of the 

elements necessary to assure the effective and econom- 
ical support of a system or equipment at all levels of 
maintenance for its programmed life cycle. The elements 
include all resources necessary to maintain and operate 
an equipment or weapons system, and are categorized as 
follows: (1) planned maintenance, (2) logistic support 

personnel, (3) technical logistic data and information, 

(4) support equipment, (5) spares and repair parts, (6) 
facilities, and (7) contract maintenance. 

21. INTERMEDIATE LEVEL ; The middle level of the three levels 
of maintenance. 

22. KIT ; A collection of carefully identified and controlled 
items used to build a module, printed circuit board, sub- 
assembly or assembly. 

23. LIFE CYCLE ; The period covering the design, development, 
manufacture, operation, maintenance, logistic support and 
repair of an equipment. 

24. MODIFICATION ; A change to an equipment and spares allowed 
only after the contract has been revised. 

25. NAVAL AVIATION MAINTENANCE PROGRAM (NAMP) ; The system 
prescribed by Chief of Naval Operations Instruction 4790. 2B 
to manage overall aviation maintenance within the Navy. 

26. ORGANIZATION LEVEL ; The lowest of the three levels of 
maintenance. In aviation it is the squadron level. 

27. PRODUCT BASELINE ; The product configuration identification 
initially approved by the customer. 

28. SHOP REPLACEABLE ASSEMBLY (SRA) ; A subcomponent of a wea- 
pon replaceable assembly removed as a result of an inter- 
mediate level maintenance action. 

29. SUBASSEMBLY ; Two or more parts that form a portion of an 
assembly replaceable as a whole but having a part or parts 
that are individually replaceable. 

30. SUBSYSTEM ; A major functional subsystem or group of items 
that is essential to operation completeness of a system. 

31. SYSTEM ; A composite of subsystems, assemblies, skills, 
and techniques capable of performing and/or supporting 
an operational (or non operational) role. A complete 
system includes related facilities, items, material, 
services and personnel required for its operation. 
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TECHNICAL DIRECTIVE ; An official document describing 
technical information, instructions and safety procedures 
related to operation, maintenance, installing or modifi- 
cation of an equipment. 

33. TECHNICAL DIRECTIVE INDEX ; A record of all technical 
directives by weapon system, weapon, system, or commodity 
from the date the technical directive number is assigned 
until the technical directive is rescinded or cancelled. 

34. TECHNICAL DIRECTIVE COMPLIANCE STATUS REPORTS ; A series 
of reports that record the compliance status of all formal 
and interim changes in the NAVAIR system, including kits, 
material, and manhour information. 

35. TYPE/MODEL/SERIES (T/M/S) : Refers to the type, model and 

series of aircraft in the NAVAIR inventory (i.e., A-4J — 

A is type Attack, 4 is the model and J is the series) . 

36. VALIDATION ; As used herein, validation comprises those 
evaluation, integration and test activities carried out 
at the system level to assure that the finally developed 
systems satisfy the mission requirements of the system 
specifications . 

37 . VISUAL INFORMATION DISPLAY SYSTEM/MAINTENANCE ACTION FORM 
(VIDS/MAF) ; The single form used to document all main- 
tenance actions in support of the aviation Maintenance 
and Material Management System. 

38. WEAPON REPLACEABLE ASSEMBLY (WRA) ; A component removed 
from an aircraft by an organizational level maintenance 
action . 
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